I have just received an email from my domain hosting provider (Cloudflare), advising me that my Let's Encrypt certificate will expire on 11-March-2025. However when I run certbot it tells me that my certificate expires on 22-May-2025. How can I determine which is correct, and any idea why Cloudflare might be giving me a different date to certbot?
My domain is:home.richmondtech.co.uk
I ran this command:
ssl-cert-check -c /etc/letsencrypt/live/home.richmondtech.co.uk/fullchain.pem
It produced this output:
FILE:/etc/letsencrypt/live/home.richmondtech.co.uk/fullchain.pem Valid May 22, 2025 88
I'm not familiar with the Cloudflare expiry email service (just with the soon-to-be-gone expiry emails from Let's Encrypt themselves), but it might be because your certificate from 2024-12-11 included a wildcard hostname while all the other more recent certs do not. See e.g. https://crt.sh/?deduplicate=Y&q=home.richmondtech.co.uk for more info.
Might be a good idea to check when Cloudflare sends these expiry emails, i.e., what conditions are necessary for them to send emails.
Thanks for your reply. I did go around alot of loops when I set this cert up at the end of last year, as I was also implementing a reverse proxy and wasn't sure which of the two servers was actually serving the definitive SSL certificate (the endpoint is a Home Assistant server, which has the LetsEncrypt add-on installed). The Ubuntu server is where I am running the reverse proxy (and the certbot command).
If I look at the certificate expiry details in a Chrome browser it shows an expiry date of 22-May-2025 for home.richmondtech.co.uk, which is consistent with the email from Cloudflare.
Could it be that the certificate is being served from the endpoint (not the reverse proxy server), and that this cert has the wildcard hostname? If so, is there a way of removing the wildcard cert?
It is NOT consistent as you said earlier the Cloudflare email mentioned a cert expiring on 11th of March, not May.
Could be, maybe your HA LE addon got the wildcard cert? But if HA is behind a reverse proxy where the reverse proxy does all the TLS, there is no need for the HA instance to have TLS too, assuming the connection between the reverse proxy and HA instance is secure.
Yes that was my understanding - which is why I installed the cert on the machine running the reverse proxy. But it seems that the cert is still being served by the HA LE add-on, which I just checked and does indeed have certificates for both home.richmondtech.co.uk and *.home.richmondtech.co.uk.
It reports the cert for home.richmondtech.co.uk expiring on 24-May-2025 (rather than the 22-May-2025 reported by certbot on the Ubuntu server):
Renewing an existing certificate for home.richmondtech.co.uk and .home.richmondtech.co.uk Waiting 60 seconds for DNS changes to propagate
Successfully received certificate.*
Certificate is saved at: /data/letsencrypt/live/home.richmondtech.co.uk/fullchain.pem*
Key is saved at: /data/letsencrypt/live/home.richmondtech.co.uk/privkey.pem*
This certificate expires on 2025-05-24.*
These files will be updated when the certificate renews.*
I suspect that I've made a mistake in configuring the reverse proxy, but I'm now baffled by the different expiry dates being reported.
My web browser reports an expiry date of 22-March-2025:
This is most likely because web browsers connect to the reverse proxy and Certbot is in charge of managing the reverse proxy certificate.
That's because apparently you just got that renewed, but nothing is directly connecting to HA, but through the reverse proxy, so nothing on the web "sees" your HA certificate.
As said, I'm not familiar with the Cloudflare expiry service, but it probably just informed you that the previous (superfluous) HA cert was expiring. And nobody cares, because your reverse proxy is doing the TLS stuff anyway.
If your reverse proxy is set up to connect to HA using HTTP (which is fine if that "internal" connection is secure), then HA doesn't need a certificate.
It seems logical that the web browser would connect to the reverse proxy, but if that's the case then I don't understand why the web browser reports an expiry date of 22-March-2025, whereas running certbot on the reverse proxy server reports an expiry date of 22-May-2025?
So maybe your chrome connects to HA internally instead of the reverse proxy? Check with your mobile phone without WiFi if necessary. It should say May.
Also, publicly trusted certificates aren't allowed to be directly signed by a root certificate, thus this indicates to me this even isn't a trusted certificate. Did your phones webbrowser trust this cert or did you get a warning?
Ah OK I've realised why I got the strange result from the phone...I have a passive IPSOS market research app running on my phone, which requires a VPN and associated certificate. That's probably the one being reported.
If I connect to home.richmondtech.co.uk from a VPN I get an expiry date of 22-May-2025 (i.e. the date reported by certbot on the reverse proxy server). So I guess that the outside world is seeing a certificate which will expire on 22-May-2025, which is good?
If so, hopefully I can ignore the email from Cloudflare, as maybe it was reporting on an old or irrelevant cert.
My browser may be connecting internally to HA, which doesn't explain the strange expiry date of 22-Mar-2025, but hopefully won't be a problem...
Is there any way that I can trace back the certs listed on crt.sh to the machine that generated them?
You also just renewed the HA cert, right? So it should not give you an expiry date of 22 March any longer.
Nope, not directly as in that crt.sh tells you a cert was issued by the HA LE addon. You can cross-reference the serials though, but that means you should know where to look for certs internally and check the certs serial number with the ones from crt.sh.
I can access the file system of the HA server, and can see the fullchain.pem and privkey.pem files, for example. Which files will contain the serial number of the certs?
HA did try to renew the cert when I restarted the LE integration, but I still see an expiration date of 22-March-2025 in my Chrome browser
If I run openssl x509 -noout -serial -in ssl/fullchain.pem I get a 36 character serial code returned. This doesn't correspond to the 11 digit serial numbers on crt.sh ???
If I run the command on the privkey.pem file (the only other file in the ssl folder), I get "Could not extract certificate from ./ssl/privkey.pem ....unsupported crypto
I now see that if I click on that ID I get to see details of the certificate (including the serial number). Unfortunately that link now seems to broken - I'm getting "502 Bad gateway" :0(
