Imagine a car that has a check-engine light, but the light only checks the fuel level.
The fuel light is useful. You should know when you're running low. But you'd be uncomfortable in a car that didn't also tell you about engine temperature, oil pressure, brake wear, tyre pressure, or the alternator. You'd assume the dashboard was incomplete. You'd expect the warranty to come with an asterisk.
Most certificate monitoring is exactly that car. It watches the fuel level - the expiry date - and not much else. When the cert is going to run out in fourteen days, you get an email. Otherwise the dashboard stays green.
This is fine, until it isn't. Because TLS certificates fail in at least four ways that have nothing to do with the date on them. The dashboard says green; the cert is silently broken; the customers see the warnings before you do.
Here is what expiry-only monitoring misses, why the industry settled for it, and what real monitoring actually has to cover.
The four failure modes nobody checks
Chain breaks. Every cert is part of a chain - your server's cert is signed by an intermediate CA, which is signed by a root CA, which lives in browser trust stores. The chain has to be complete for the cert to be trusted. Intermediates get rotated. Cross-signs expire. Servers serve the wrong intermediate. Older Android phones, older Java apps, and older curl versions are especially sensitive - they may refuse certs that Chrome accepts. The Let's Encrypt cross-sign expiry in September 2024 (the IdenTrust cross-sign on ISRG Root X1) is the canonical example - it was a chain-validation problem caused by an upstream expiry, not by your own cert expiring.
Cipher decay. Your cert is fine. Your server's cipher list, configured three years ago by an engineer who left, includes a cipher that's now considered weak. Modern browsers refuse to negotiate it. Mobile users - whose TLS libraries update faster than your servers - fail first. The cert never expires. The connection just fails for an increasing percentage of clients.
Hostname and SAN mismatches. A wildcard cert covers *.example.com. The team launches api.eu.example.com - two dots deep - and discovers the wildcard doesn't cover it. A SAN list gets truncated during a renewal and staging.example.com falls out. The cert is valid. It just doesn't match the hostname your visitors are using.
Revocation. A cert can be valid by its dates and still be revoked by the CA - because of a key compromise, a misissuance, or a CA mistake. Browsers may or may not check revocation in real time. The cert looks fine in your dashboard. Some users get warnings; others don't.
The expiry date is the loudest failure mode. The other four are quiet, and quiet is what gets through.
Why expiry monitoring became the default
History, mostly.
For most of the public web's life, certs were issued for two or three years. The interesting question was "when does it expire?" because that was the only thing that changed predictably. Ciphers were stable. Chains were stable. CAs revoked very rarely.
Monitoring tools were built around this assumption. Pingdom-style uptime monitors started checking certs as a feature add-on. Nagios had a cert-expiry plugin. The industry settled on "let me know thirty days before expiry" as the model, and the model became the product.
Two things changed.
One: cipher suites started moving faster. TLS 1.0 and 1.1 were officially deprecated. SHA-1 went out. Various ciphers became non-recommended. Servers that didn't keep up started failing for newer clients without ever expiring.
Two: shorter cert lifespans turned chain churn into a regular event. With 90-day and shorter certs, intermediates change more often, cross-signs come and go, and the "stable infrastructure" assumption no longer holds.
The fuel-light dashboard hasn't caught up. Most monitoring still alerts on expiry, and treats everything else as either "out of scope" or "a network thing."
What real monitoring actually covers
If your monitoring stops at the expiry date, you're catching maybe a third of the actual failure modes. Here's what a complete check looks like.
Expiry, of course. With warnings escalating as the date gets closer - thirty days, fourteen, seven, three. Not a single alert at thirty days that everyone ignores.
Full chain validation. Connect to your endpoint, fetch the full chain, walk it against modern trust stores (browsers, Android, Java, Windows) and report which clients would refuse it. Not just "does it validate at all" - does it validate for the people who actually visit your site.
Cipher and protocol scan. Which TLS versions and ciphers does your server accept? Are any of them deprecated? Would a modern browser refuse to negotiate? Is TLS 1.3 enabled?
Hostname and SAN coverage. Does the cert actually cover the hostname you're serving? Including subdomains. Including the alternate spelling that came in last sprint.
Revocation status. OCSP, CRL, and CRLite - does the cert appear in any list of revoked certs? Has the CA quietly invalidated it?
Known vulnerabilities. Is the server vulnerable to historical TLS issues (Heartbleed, ROBOT, weak Diffie-Hellman, etc.)? Mostly old, mostly patched, and still occasionally found in production.
None of these are exotic. They're table stakes for any monitoring that takes itself seriously. But many tools still treat them as premium features or leave them out entirely.
What "good" looks like
Good cert monitoring looks like a check from outside, not a check from inside.
If your monitor lives on the same server as the cert, it shares the same blind spots. It trusts the same chain. It uses the same cipher list. If something's wrong with the server's view of its own certs, you won't catch it.
Good monitoring talks to your endpoint the way a real user does. Different geography. Different TLS client. Different trust store. It reports what the visitor sees, not what the server thinks it's serving.
This is, not coincidentally, exactly what TLS Radar is built to do. We check from the outside, across all the failure modes above, and we don't trust your renewal pipeline to tell us it worked. The free tier covers three domains. That's enough to see whether your current monitoring is checking what you think it's checking.
One small ask
Run your current monitor against this list. If it only covers expiry, you have a fuel light, not a dashboard.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.