Reinstalling an expired cert not successful

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: tcc.planchurch.com

I ran this command:

  1. certbot-auto delete -d tcc.planchurch.com
  2. certbot-auto
    and select the domain tcc.planchurch.com to install

It produced this output:
3. Install is successful, but when I visit the url the the new cert is not activated and displays as 'insecure'. I have attempted the reinstall a few times and so I am afraid I have exceeded the max number of reinstall allowed. So currently I am not able to reinstall the cert.

However, when I test the SSL using the following url, I still see the the test detects the old version of the SSL cert:

My web server is (include version):
Apache 2.4.6

The operating system my web server runs on is (include version):
CentOS Linux 7

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):
Yes. I can login

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot ver: 1.10.1

Please stop deleting working certs.
You have already issued five certs (with that same exact name) today:

Certificate renewals do NOT require the deletion of the previous/existing cert.
Remove that step from your process altogether.
Once a cert has been issued, you only need to renew it:
certbot renew

Before doing anything else, please show the output of:
certbot certificates

1 Like

If the problem is with installing a cert (and not with issuance), renewal isn't helpful at all.. The installation part should be debugged.

1 Like

I had to 'delete' the cert and could not 'renew' since the cert had already 'expired'.
And since after each attempt to 'reinstall' the cert the url was displaying 'not safe' I attempted to fix the problem by attempting to 'force renew'. Since that did not seem to fix the problem, I deleted and attempted to reinstall. Now after 5 attempts looks like I have to wait for 168hrs before I can reinstall.

Currently there is no cert installed, since I have exceeded the number of installs allowed. But as you can see from the screenshot the SSL cert test, still retrieves the 'expired' cert. Can someone explain, where this 'expired' cert is still stored and whether this is the reason why even after I have reinstalled the cert, the site url still displays 'not safe' ??

Hi @festus,

certbot renew is perfectly happy to renew certificates after they have already expired. There is no need to delete them. (If you do delete them, then you can no longer use certbot renew because Certbot can no longer find anything to guide its renewal effort.)

It seems most likely that you have a different certificate name (e.g., Certbot could have created a certificate called tcc.planchurch.com-0001 or something) which your site is using.

There is also a somewhat obscure Apache bug in which Apache can sometimes be incompletely restarted, in which case it still randomly uses old configurations for some requests (including old certificates).

What @rg305 said above is very helpful advice:

This command shows what certificates are currently managed by Certbot, including their names, coverage, and expiration status. This is typically very important information, and can be helpful in figuring out why Certbot or your server is not doing what you expect. For example, if you have a duplicate certificate with -0001 or something, this command will show it to you.

(The reason for the -0001 certificates, which I suggested is the most likely possibility here although not the only possibility, has to do with Certbot's behavior when you change the domain name coverage compared to a previously-issued certificate, usually by providing an even slightly different list of subdomains. In this case, Certbot can end up managing one certificate covering one list of names, and another certificate covering a slightly different list of names. This can certainly be confusing and is also, as it turns out, not the behavior most users intended much of the time.)

As @Osiris mentioned, there are also separate steps of obtaining a certificate and installing that certificate into a web server application's configuration (like Apache's configuration). Typically, Certbot will handle both of these steps, but it's also quite possible for one of them to succeed and the other to fail. For instance, if you have an older version of Certbot (which is unfortunately possible with certbot-auto, which is no longer receiving software updates), and if it doesn't understand your Apache configuration properly, it might not be able to make the correct configuration changes to Apache to cause it to use the newly-obtained certificate.

Alternatively, if your Apache configuration is hand-written and is erroneous or self-contradictory in certain ways, that can also end up configuring Certbot. A common example of this is Apache configurations that define the same VirtualHost repeatedly in multiple different locations. According to Apache documentation, this is not correct, yet Apache is still willing to run with such a configuration (and apparently guess which VirtualHost definition should be used). (@rg305 has referred to this as "running at all costs".) With such a configuration, Certbot will also effectively end up guessing which version of the VirtualHost definition to set up with the new certificate, and it unfortunately may not be the same one that Apache guesses it should use for its own configuration.

I don't know for sure that this situation is relevant to you, but I'm just providing it as an another example of how things can get confused in your configuration—in which case repeating the same issuance/renewal/deletion process will not be able to make progress. Instead, whatever has gone wrong with the configuration will need to be fixed first.

3 Likes

Appreciate the detailed explanation provided and possible root causes.
I have several domains hosted in a virtual server.
I had to make the same steps for all the domains, by deleting the 'expired' cert and running the install command:
# certbot-auto certonly -d tcc.planchurch.com

As an example, I reinstalled the cert for the domain 'ch0101.planchurch.com' using the 'delete', 're-install' steps using following commands:

# certbot delete --cert-name ch0101.planchurch.com
# certbot-auto certonly -d ch0101.planchurch.com

The ssl for the domain 'ch0101.planchurch.com' successfully installed along with several other domains. Only the domain tcc.planchurch.com failed to secure the site. Since I exceeded the 5 counts to request for a new cert, I am not able to install the new cert for the domain tcc.planchurch.com. I probably need to wait for a few more days (168hrs). Therefore when I run the command to list the certs, I can only display the status for 'ch0101.planchurch.com' but not for 'tcc.planchurch.com'.

I am uploading the response I got by running both 'certbot certificates' as well as 'certbot-auto certificates'. I have all along been using 'certbot-auto' although I do get the warning that the 'certbot-auto' will not be automatically updated.

And I cannot figure out how to get the updates. Wonder if the older version of certbot is the root cause. In that case why only this one domain 'tcc.planchurch.com' cannot successfully install, and all others are successful.....Appreciate your advise.
220513-vm139-certbot-certificates.txt (1.7 KB)

Where did you "learn" to delete first to update a cert?

This is very interesting:
Attempting to parse the version 1.10.1 renewal configuration file found at /etc/letsencrypt/renewal/ch0101.planchurch.com.conf with version 0.35.1 of Certbot. This might not work.

Please show:
which certbot
find / -name certbot

1 Like

These steps are both entirely wrong:

1: you don't need to delete a certificate to re-install it;
2: you're using certonly which won't even re-install anything into any service, it would just re-issue the certificate, not re-install. With certonly you need to do the (re-)installing part manually. That's why it's called "certonly": "only get a certificate, nothing more".

My advice to you is to learn more about the things you're doing and/or trying to do before doing it.

3 Likes

# find / -name certbot
/etc/sysconfig/certbot
/usr/lib/python2.7/site-packages/certbot
/usr/bin/certbot
/opt/eff.org/certbot
/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot
/opt/eff.org/certbot/venv/bin/certbot

what about?:

1 Like

Should I use 'certbot' command or 'certbot-auto' command?
I have all along been using 'certbot-auto' and it has worked for me even though I do get the warning as follows:

# certbot-auto
Your system is not supported by certbot-auto anymore.
certbot-auto and its Certbot installation will no longer receive updates.
You will not receive any bug fixes including those fixing server compatibility
or security problems.
Please visit https://certbot.eff.org/ to check for other alternatives.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

I tried using 'certbot' only after I failed to successfully install ssl for the domain 'tcc.planchurch.com'.

Appreciate all the help I am receiving so far. Hopefully I can find the root cause and find the correct steps, especially if a domain expired because I forgot to renew before expirty.

1 Like

certbot-auto is deprecated and should be removed.
But I wonder where 1.10.1 came from?:

1 Like

# which certbot
/usr/bin/certbot

Does not display the certbot version

For the version do:
certbot --version

1 Like

# certbot --version
certbot 0.35.1

That is quite old, but we can work with it (for now).
We have a bigger problem - you site cert is expired:
SSL Server Test: tcc.planchurch.com (Powered by Qualys SSL Labs)

Please show the output of:
apachectl -t -D DUMP_VHOSTS

1 Like

# apachectl -t -D DUMP_VHOSTS

Passing arguments to httpd using apachectl is no longer supported.
You can only start/stop/restart httpd using this script.
If you want to pass extra arguments to httpd, edit the
/etc/sysconfig/httpd config file.
VirtualHost configuration:
*:443 is a NameVirtualHost
default server localhost.localdomain (/etc/httpd/conf.d/ssl.conf:62)
port 443 namevhost localhost.localdomain (/etc/httpd/conf.d/ssl.conf:62)
port 443 namevhost ch0101.planchurch.com (/etc/httpd/sites-available/ch0101.planchurch.com-le-ssl.conf:2)

*:80 is a NameVirtualHost
default server localhost.localdomain (/etc/httpd/conf.d/churchcrm.conf:1)
port 80 namevhost localhost.localdomain (/etc/httpd/conf.d/churchcrm.conf:1)
port 80 namevhost ch0101.planchurch.com (/etc/httpd/sites-enabled/ch0101.plnchurch.com.conf:1)
port 80 namevhost tcc.planchurch.com (/etc/httpd/sites-enabled/tcc.planchurch.com.conf:2)

As I mentioned before, since I exceeded the max ssl requests (5) I am not able to install ssl for the domain 'tcc.planchurch.com' for a few more days.

It seems that your secure vhost is missing.
["tcc.planchurch.com" does not appear in the "*:443" section]

Please show the outputs of:
ls -l /etc/httpd/sites-available/
ls -l /etc/httpd/sites-enabled/

1 Like

I fully understand the problem and I'm prepared to help you fix it now.

1 Like