When a TLS certificate expires and nobody notices

A TLS certificate almost never expires “all of a sudden”. It expires on a known date, written into the certificate itself, often auto-renewable. Yet the outage stays common: browser error page, API handshake failure, monitoring that only fires once the service is already red.

The pattern

1. ACME renewal is supposed to run.
2. A reboot, a wrong virtual host, or a missing intermediate leaves the old file in place.
3. HTTP uptime stays green as long as port 443 answers.
4. The first useful signal comes from an external human.

The gap is not exotic technology. It is a signal gap. Uptime ≠ certificate validity ≠ domain expiry.

Minimal diagnosis

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Then cross-check:

• notAfter
• SAN coverage for the public hostname
• full chain
• monitoring: is there a probe dedicated to expiry, separate from uptime?

Durable fix

• TLS expiry probe (J-30 / J-14 / J-7), not only HTTPS ping.
• Separate domain expiry alert (RDAP/WHOIS).
• A renewal runbook tested outside production at least once.
• A monthly report that states the observed expiry date, not “all green”.

That is the sober scope of external supervision: few metrics, the right ones, with a readable history.

Prevention

If your monitoring cannot answer “in how many days does the certificate for public hostname X expire?”, it is not infrastructure supervision yet — it is outage detection.