Why Expiry Monitoring Alone Isn't Enough
Most certificate monitoring only watches the expiry date, but TLS certificates fail in at least five ways that have nothing to do with their dates: broken chains, decayed cipher suites, hostname or SAN mismatches, revocation, and trust-store distrust or EKU rejection. These failures are silent - the dashboard stays green while the site stops loading for some browsers. Complete monitoring checks the full chain, ciphers and protocols, hostname coverage, revocation, browser trust-store changes, known vulnerabilities, and post-quantum readiness, from outside your infrastructure the way a real visitor connects.
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 five ways that have nothing to do with the date on them. The dashboard says green; the cert is silently broken; the site stops opening in some browsers; 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 five 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.
Trust-store distrust and EKU rejection. A certificate can be valid, correctly chained, and still rejected because of a decision made upstream of you. Browsers distrust CAs and retire old roots on their own schedule - Chrome's constraints on the legacy SSL.com 2016 and Entrust roots are recent examples. And from March 15, 2027, Chrome will reject newly issued public certificates that carry both the serverAuth and clientAuth Extended Key Usage - a change some CAs are already enforcing early through their own policies, which is what forced HARICA's mass revocation of 63,525 certificates in July 2026. Your renewal pipeline can hand you a cert this week that a browser refuses. Nothing about the expiry date warns you.
The expiry date is the loudest failure mode. The others 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?
Trust-store and distrust tracking. Watch the browser root programs (Chrome, Mozilla, Apple, Microsoft) for distrust events and discontinued roots, and flag the EKU combinations browsers now reject. These are the failures that come from the CA side, not yours - and expiry monitoring is blind to all of them.
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.
Post-quantum readiness. The handshake itself is changing. Browsers are rolling out hybrid post-quantum key exchange, and servers that lag will negotiate down or fail for updated clients - the same pattern as cipher decay, one layer deeper. Knowing where you stand now is cheap; finding out from a broken handshake later is not.
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.
Frequently asked questions
- Is monitoring only a certificate's expiry date enough?
- No. Expiry is the loudest failure mode but only about a third of them. A certificate can be valid by its dates and still fail because of a broken chain, a weak cipher, a hostname or SAN mismatch, a revocation, or a browser distrusting its root. These are silent - your expiry dashboard stays green while the site fails for some visitors.
- What can go wrong with a certificate that hasn't expired?
- Five common things: the certificate chain is incomplete or an intermediate expired; the server negotiates a cipher modern browsers refuse; the certificate does not cover the exact hostname being served; the CA revoked the certificate; or a browser stopped trusting the root it chains to. Each fails while the expiry date still looks fine.
- What should complete TLS certificate monitoring check?
- Expiry with escalating warnings, full chain validation against modern trust stores, cipher and protocol scanning, hostname and SAN coverage, revocation status via OCSP/CRL/CRLite, browser trust-store and distrust tracking, known TLS vulnerabilities, and post-quantum readiness - all checked from outside your infrastructure the way a real user connects.
- Why check certificates from outside instead of on the server?
- A monitor on the same server shares the certificate's blind spots: it trusts the same chain and uses the same cipher list, so it cannot see problems with the server's own view of its certificates. An external check connects the way a real visitor does - different network, TLS client, and trust store - and reports what the visitor actually sees.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.