Please replace the Expired Certificate (good idea to keep a copy until it is all working) with the New Certificate. And then restart the Apache server service or reboot the machine.
2 Likes
I tried that, but the problem is that the new certificate is not recognized. Checks still result in "certificate expired" messages.
@twellit, the site is serving 04:60:8E:71:E6:6F:E9:10:EE:06:95:80:61:5E:60:F8:2A:42 — that is, this certificate. Can you find that certificate anywhere on your server's disk now? Can you find any reference to it in your server's configuration file?
5 Likes
Sorry, I am not that experienced with this. Do I have to look for a .cert file? What would be a reference to the certificate?
A worthwhile thing to try first is sudo certbot certificates; after that you could conceivably try
sudo find /etc -name '*pem' -print -exec openssl x509 -serial -noout -in '{}' ';' 2>/dev/null | grep -B 1 04608E71E6
or more ambitiously
sudo find /etc -print -exec openssl x509 -serial -noout -in '{}' ';' 2>/dev/null | grep -B 1 04608E71E6
I predict you most likely have an overlapping or duplicative certificate under a slightly different certificate name (like -0000) in /etc/letsencrypt somewhere.
5 Likes
sudo certbot certificates gives me this:
Found the following certs:
Certificate Name: travelintaiwan.net
Serial Number: 32d038eba11cabeefb0ce928805cab39d5d
Key Type: RSA
Domains: travelintaiwan.net www.travelintaiwan.net
Expiry Date: 2023-06-04 06:11:38+00:00 (VALID: 88 days)
Certificate Path: /etc/letsencrypt/live/travelintaiwan.net/fullchain.pem
Private Key Path: /etc/letsencrypt/live/travelintaiwan.net/privkey.pem
Do you mean this:
[root@*** letsencrypt]# cd keys
[root@*** keys]# ls
0000_key-certbot.pem 0004_key-certbot.pem 0008_key-certbot.pem 0012_key-certbot.pem 0016_key-certbot.pem 0020_key-certbot.pem 0024_key-certbot.pem
0001_key-certbot.pem 0005_key-certbot.pem 0009_key-certbot.pem 0013_key-certbot.pem 0017_key-certbot.pem 0021_key-certbot.pem
0002_key-certbot.pem 0006_key-certbot.pem 0010_key-certbot.pem 0014_key-certbot.pem 0018_key-certbot.pem 0022_key-certbot.pem
0003_key-certbot.pem 0007_key-certbot.pem 0011_key-certbot.pem 0015_key-certbot.pem 0019_key-certbot.pem 0023_key-certbot.pem
Should I just delete them starting with 0001?
There is no need to delete any of them - that won't fix anything [it will only clear up a little bit of disk space].
3 Likes
Nope, and apparently my first guess was wrong!
I'm pretty confused about what is broken, but maybe you could try the find command that I posted above!
3 Likes
I don't get any results when trying both of your suggested commands, unfortunately.
Should there be a cert1 and a cert 2?
/etc/letsencrypt/archive/travelintaiwan.net/cert1.pem
/etc/letsencrypt/archive/travelintaiwan.net/privkey1.pem
/etc/letsencrypt/archive/travelintaiwan.net/chain1.pem
/etc/letsencrypt/archive/travelintaiwan.net/fullchain1.pem
/etc/letsencrypt/archive/travelintaiwan.net/privkey2.pem
/etc/letsencrypt/archive/travelintaiwan.net/cert2.pem
/etc/letsencrypt/archive/travelintaiwan.net/chain2.pem
/etc/letsencrypt/archive/travelintaiwan.net/fullchain2.pem
/etc/letsencrypt/live/travelintaiwan.net/cert.pem
/etc/letsencrypt/live/travelintaiwan.net/privkey.pem
/etc/letsencrypt/live/travelintaiwan.net/chain.pem
/etc/letsencrypt/live/travelintaiwan.net/fullchain.pem
Yes, there should be. (That's the old version and new version.)
Is there any other device involved here that the old certificate might be installed on, like a firewall or proxy server or load balancer?
2 Likes
There might be a pfx file stored somewhere. We had to provide a pfx file to the people where the server is located. Not sure what they did with that file and where it was stored. Will ask. Thanks!
Oooh, yeah, that would be really important. If that file is in use somewhere, it needs to be regenerated and replaced every time the certificate is renewed!
We can write scripts to help with that, but that could explain a lot about the current problems.
3 Likes
OK, finally light at the end of the tunnel! They used that file for a WAF, but didn't tell us to renew the file each time, which of course we newbies didn't think about. So I will create a new pfx and see how that goes.
What is the best way to create a pfx file, btw?
If there would be a script we could use, that would be great.
Thanks for pointing me to the problem!
3 Likes
Problem solved! What a relieve!
Thanks, y'all! This is a very helpful community!
3 Likes
I'm glad it worked!
How do you submit the PFX file to the people maintaining the WAF? By e-mail? With a web form? Is there a way to upload it directly there rather than sending it to other human beings?
3 Likes
I just save it in a temporary folder, and they grab it. I don't know what they then do with the firewall.
Not a big deal to renew the certificate every 90 days and then save that file. Just glad that the problem is solved. 
1 Like
The Certbot documentation describes the option to use a deploy hook:
--deploy-hook DEPLOY_HOOK
Command to be run in a shell once for each
successfully issued certificate. For this command, the
shell variable $RENEWED_LINEAGE will point to the
config live subdirectory (for example,
"/etc/letsencrypt/live/example.com") containing the
new certificates and keys; the shell variable
$RENEWED_DOMAINS will contain a space-delimited list
of renewed certificate domains (for example,
"example.com www.example.com") (default: None)
This command would be run automatically by Certbot whenever the certificate is renewed, so you can make it do however much of your new certificate deployment process can be automated (e.g. creating the PFX file using an openssl pkcs12 command, copying it to a specific location, maybe sending an e-mail to someone about it?).
The amount that you can automate with scripting obviously varies a lot in different environments. 
5 Likes