The Silent TLS Failures Your Expiry Monitor Doesn't Catch
Expiry is the loudest failure mode for TLS certificates. It's also the easiest one to monitor for and the one that most homegrown scripts catch. Which is why the failures that take production down most often aren't expiry.
They're the silent ones. The cert is valid by its dates. Your monitoring says it's fine. Customers still see warnings. Your support queue starts filling up, and the on-call engineer spends an hour figuring out what's actually broken because the alerting didn't fire.
The four silent failure modes that matter
In rough order of how often they cause real outages:
Chain breaks
Every public TLS certificate has an issuer chain back to a trusted root. Your server has to send the leaf cert plus all intermediates. If your server only sends the leaf, browsers that have the intermediate cached are fine; browsers that don't, fail.
Common ways this happens: a CA rotates its intermediates and you keep serving the old one (most browsers still trust the old intermediate for a while, then stop). A renewal script overwrites the chain file with just the leaf, losing the intermediates. A load balancer config drift drops the intermediate on one of N hosts. A new edge node spins up without the chain file.
The cert is "valid." The chain is broken. Modern Chrome handles it via AIA chasing. Older Android, some embedded devices, and most compliance scanners do not. Mobile traffic is usually the first to break.
Weak ciphers
Your TLS config from 2019 includes cipher suites that were considered acceptable then. The CA/Browser Forum, the IETF, and browser vendors deprecate ciphers continuously. CBC-mode ciphers, certain RSA key exchanges, anything based on SHA-1 - all have been progressively removed from default browser support over the past few years.
Your server might still offer them. Modern clients negotiate a stronger cipher and don't notice. Older clients (embedded devices, legacy mobile apps, certain test environments) fall back to a weak cipher you didn't realize was still being offered. Compliance scanners (PCI ASVs, SOC 2 auditors) flag them. The cert hasn't expired. The site isn't down. But something is broken, and you find out at audit time.
Hostname mismatches
Three common variants. Wildcard depth: a *.example.com cert covers a.example.com but not a.b.example.com. A new subdomain three levels deep isn't covered. SAN list truncation: a renewal regenerates the cert with a shorter SAN list than the original; some hostnames that worked yesterday don't today. Subject Common Name mismatch: legacy clients that still validate against CN (not SAN) fail when the CN doesn't match the requested hostname.
Symptom: a specific subset of your domains throws warnings on a specific subset of clients. Not catastrophic, easy to miss until someone files a ticket.
OCSP revocation
A cert can be revoked by its issuer before its natural expiry. Reasons: key compromise, mis-issuance, voluntary revocation when a service is decommissioned, CA-side cleanup. Browsers check revocation status via OCSP, OCSP stapling, or CRLs.
If a cert is revoked and you don't notice, your site starts throwing warnings for clients that check revocation. The exact behavior varies by browser - Chrome uses CRLSets selectively, Firefox enforces more strictly, Safari is somewhere in between - but the failure surface is large.
Most homegrown monitoring doesn't check revocation status. The cert is "valid by date," so the script reports green. The customer's browser disagrees.
Why expiry-only monitoring misses all of these
Because none of them change the expiry date. Your cron runs, reads notAfter, compares to now, and concludes the cert is fine. By the standard of "is the date in the future" it is fine. By the standard of "will a real browser trust this cert," it might not be.
The four failure modes above require continuous probing with a full TLS handshake validation, not a date check. They require the same kind of validation logic that a modern browser does: build the chain, verify each link, check revocation, validate the hostname against SAN, negotiate a strong cipher. Anything less misses real failures.
Check your own certs
Run a domain you care about through an SSL scanner that does full handshake validation. Look at the chain depth (are all intermediates present?), the cipher negotiated (modern? deprecated?), the SAN coverage (does it actually include every hostname you use?), and the revocation status (OCSP responding, not revoked). One scan reveals the silent failures that your monitoring is probably missing.
Catch the failures that don't fire expiry alerts
TLS Radar runs full TLS handshake validation against every certificate in your inventory. Chain validity, hostname coverage, cipher strength, OCSP revocation, protocol compliance - all continuously, from outside your network. Alerts you when something breaks that wouldn't trip an expiry check. Built to scale from a handful of sites to enterprise portfolios with API integration, SAML/SSO, and pricing that fits your certificate volume.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.