TLS · 3 steps

A certificate expired

Find which certificate in the chain actually expired, why a renewal did not take effect, and every other place the same certificate is deployed.

Every step

Read the dates from what is actually being served

The certificate on disk and the certificate in the server’s memory are different things, and only one of them is reaching clients. Always read it off the live endpoint before touching anything.

$ echo | openssl s_client -connect <host>:443 -servername <host> 2>/dev/null | openssl x509 -noout -subject -dates

$ curl -sv https://<host> 2>&1 | grep -E "expire|subject|issuer"

$ openssl x509 -in /etc/ssl/certs/server.crt -noout -dates # what is on disk, for comparison

Look for: `notAfter` on the served certificate, and whether it matches the file on disk. A difference between the two is the whole answer.

Establish whether a renewal was even attempted

An expired certificate is usually not a TLS problem at all — it is an automation problem that failed quietly weeks ago. Find out whether the renewal ran and failed, or never ran.

$ certbot certificates

$ systemctl status certbot.timer snap.certbot.renew.timer

$ journalctl -u certbot -S -30d --no-pager | tail -40

$ kubectl describe certificate <name> -n <ns> # cert-manager

Look for: The last renewal attempt and its result. For cert-manager, the `Status` conditions and events on the Certificate object.

Check the intermediates, not just the leaf

Intermediates expire too, and on their own schedule. A perfectly valid leaf behind an expired intermediate fails for every client that does not fetch the issuer itself — which is most non-browser clients.

$ echo | openssl s_client -connect <host>:443 -servername <host> -showcerts 2>/dev/null | awk '/BEGIN/{n++} {print > ("cert" n ".pem")}'

$ for f in cert*.pem; do echo -n "$f "; openssl x509 -in $f -noout -subject -enddate; done

Look for: The notAfter of every certificate the server sends, not only the first one.