Table of Contents
Introduction
Fixing certificate problems can be really hard, but not if you have the right tools. Let’s do a quick exercise for HTTPS:
Port 443
openssl s_client -connect mail.example.com:443 -servername mail.example.com | openssl x509 -noout -dates Warning: Reading certificate from stdin since no -in or -new option is given depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1 verify return:1 depth=1 C=US, O=Let's Encrypt, CN=R3 verify return:1 depth=0 CN=mail.wrongdomain.com verify return:1 notBefore=Feb 1 13:16:14 2024 GMT notAfter=May 1 13:16:13 2024 GMT
Above is problematic:
- CN is wrong domain
- notAfter is today. It should have renewed already!
443 – Digger Deeper
Let’s see what’s going on with Let’s Encrypt using certbot certificates:
# certbot certificates Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Found the following certs: Certificate Name: server-anchor.example.com Domains: wrongdomain1.com anchor mail.rightdomain.com wrongdomain2.com webmail.rightdomain.com Expiry Date: 2024-05-01 13:16:13+00:00 (VALID: 10 hour(s)) Certificate Path: /etc/letsencrypt/live/server.example.com/fullchain.pem Private Key Path: /etc/letsencrypt/live/server.example.com/privkey.pem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
At least certbot is showing us similar information.
How can we remove these wrong domains and try to renew? Here was one command:
certbot delete --cert-name example.com
Let’s do that now:
certbot delete --cert-name mail.wrongdomain Saving debug log to /var/log/letsencrypt/letsencrypt.log No certificate found with name mail.wrongdomain (expected /etc/letsencrypt/renewal/mail.wrongdomain.conf).
Well that didn’t work. Mmmm.
It turns out more complex syntax is needed when removing domains from certbot. You can’t, you have to re-issue the certificate with all the names:
certbot certonly --cert-name anchordomain -d anchordomain -d mail.example.com -d webmail.example.com
I could choose the Apache options because the server is using it.
443 Checking CRONs for renewal of Let’s Encrypt
Often when Letsencrypt dates are wrong, it’s because there is still a lingering domain attached to the service that shouldn’t be here. By manually running the command below, one can see:
certbot renew
Once I ran that, I noticed an old DNS record was never updated. I updated the DNS, re-ran the command, and the restart Apache. This solved the problem.
Port 993
openssl s_client -CApath /etc/ssl/certs/ -connect mail.example.com:993 -brief
Port 465
openssl s_client -connect mail.example.co.za:465 -servername mail.example.co.za -showcerts | openssl x509 -noout -text | egrep -i "depth|subject:|alternative name|DNS:"
Port 465 – Digging Deeper
Port 465 checking spits out a lot of information so it’s important to focus your eyes on the correct bits. Here is an example:
openssl s_client -connect mail.example-to-test.com:465 -servername mail.example-to-test.com -showcerts | openssl x509 -noout -text | egrep -i "depth|subject:|alternative name|DNS:" depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = mail.other-primary-domain.com verify return:1 Subject: CN = mail.other-primary-domain.com X509v3 Subject Alternative Name: DNS:host.the-computer-name.com, DNS:mail.example.com, DNS:mail.dns-points-wrong.com, DNS:mail.example2.com, DNS:mail.example-to-test.com
In the example above, the discrepancy is that although the example want to test is there, there is also an alternative name where the DNS wasn’t correct. For a start, that has to be corrected. Refer to other parts of this documentation if that domain doesn’t exist anymore and has to be removed. &TL;DR: You can’t remove stuff, you have to reissue the certificate without the removed domain.