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.
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):
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
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' ??
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).
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.
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:
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.
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.
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:
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.
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.
*: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)