Certificate monitoring used to be a once-a-year chore. You had a cert good for a bit over a year, you put a reminder in the calendar, done. That era is ending. This is a practical guide to what to watch, what to ignore, and how to do it without burying yourself in false alarms.
Three things called "monitoring" that aren't the same
People say "monitor my certs" and mean very different things. There are three data sources, and only one of them tells you what your users see.
Renewal logs. Watching certbot exit codes and the renewal timer. This tells you a process on a machine you know about ran. It doesn't tell you the load balancer reloaded, or that a second server in the pool got the new cert, or that the CDN edge picked it up. Renewal success on disk is not the same as a valid cert on the wire.
Certificate Transparency logs. Every publicly trusted cert gets logged to CT. You can watch those logs to see what's being issued for your domains. This is genuinely useful for one thing, and actively misleading for another. Hold that thought.
The served certificate. Opening a real TLS connection to your endpoint and inspecting what the server actually hands back. This is the one that matters, because it's the only one that reflects what a browser, an API client, or a mail server experiences.
If you only do one thing, watch the served cert.
Why CT-based expiry alerts are noise
CT is fantastic for catching unexpected issuance. If a cert appears for your domain and you didn't ask for it, that's a signal worth an alert. Someone misconfigured a service, or a subdomain got taken over, or in the bad case an attacker got a cert. Watch CT for new issuance.
But using CT to warn you about expiry is a mistake, and it's a common one. Here's why. CT logs every cert ever issued for your domain, and it never forgets. When you rotate a cert, the old one is still in the log with its old expiry date. A monitor that scans CT and alerts on approaching expiry will happily warn you that a certificate is about to expire when you replaced that exact certificate three weeks ago. It's expiring on paper. It's not on your server anymore. Nobody is serving it.
So CT-based expiry monitoring generates a steady drip of false positives for certs you already rotated out. You learn to ignore them. Then you ignore the real one. The only way to know whether an expiring cert actually matters is to check what the server is serving. Which brings us back to the served cert.
The checklist
Here's what actually needs watching. Not a wish list, the real set.
Leaf certificate expiry. The obvious one. When does the cert on the wire expire. Check it against the endpoint, not against a file.
Intermediate and chain expiry. This is the one everyone forgets, and it has taken down large sites. Your leaf cert can be perfectly valid while a certificate above it in the chain expires. More on this in a moment, because the canonical example is worth knowing.
Hostname and SAN match. A valid, current cert that doesn't cover the name the client asked for still breaks the connection. Check that the served cert's SANs actually include the hostname you're hitting.
Non-HTTPS ports. TLS is not just port 443. Your mail stack serves certs on SMTP (465, 587), IMAPS (993), POP3S (995). Directory services use LDAPS (636). Admin panels love 8443. These certs expire too, and they're the ones nobody remembers because there's no browser throwing a warning. When your mail server's cert expires, mail just silently stops flowing.
Domain registration expiry. The cert can be flawless and it won't matter if the domain itself lapses. Registration expiry is a separate clock, queryable over RDAP, and an expired domain is a worse outage than an expired cert. Watch both.
Unexpected issuance. This is where CT earns its place. A new cert you didn't request is worth knowing about immediately.
The AddTrust story, because it will happen again
In May 2020, the AddTrust External CA Root expired. This root had been around since 2000. Plenty of certificates chained up to it. And when it expired, sites broke, even sites whose own leaf certificate was completely valid and had months left.
That's the part worth sitting with. The thing on the front door was fine. The problem was a certificate further up the chain that the site operators weren't even thinking about, because they didn't issue it and it wasn't in their renewal process. Clients that validated the full path to that expired root rejected the connection. Perfectly current leaf, dead chain, broken site.
This is exactly why "check the leaf expiry" is not enough, and why the openssl one-liner that reads notAfter on the leaf will cheerfully tell you everything's fine while an intermediate is about to take you down. You have to validate the whole chain.
Microsoft Teams went down in 2020 on an expired cert. Ericsson knocked out service for around 32 million users in 2018 on an expired cert. These are companies with real operations teams. Expired certificates are not a beginner's mistake, they're a monitoring gap.
Why this is now non-optional
Certificate lifetimes are collapsing. The CA/Browser Forum passed ballot SC-081v3, and the schedule is set: 398 days today, dropping to 200 days in March 2026, then 100, then 47 days by 2029.
Do the arithmetic. Going from a ~398-day cert to a 47-day cert is roughly nine times as many renewal events per certificate per year. Every renewal is a chance for the automation to break in one of the quiet ways: a reload that didn't happen, a challenge that stopped validating, a rate limit. Nine times the renewals is nine times the exposure. Manual tracking was already a bad idea. At 47 days it's not a thing a human can do at all.
The flip side: with certs rotating every few weeks, a fingerprint change is normal and frequent, which means your monitoring has to know the difference between an expected rotation and a genuinely unexpected cert swap. Watching a fingerprint alone gives you an alert every renewal. That's the next problem.
Not drowning in alerts
Shorter lifetimes plus more endpoints equals more noise, unless you're deliberate about it.
Dedupe. If a cert has been expiring for three days, that's one problem, not three alerts a day for three days. Group and suppress.
Be auto-renew aware. A fingerprint change on a cert that renewed exactly on schedule with a fresh 47-day validity is the system working. Don't page someone for it. A fingerprint change with no corresponding renewal, or a cert that suddenly chains differently, is worth a look. The monitor should tell those apart.
Threshold escalation, not a firehose. Alerts at 30, 14, 7, and 1 day before expiry give you a runway and a rising urgency. A single alert at some arbitrary point either comes too early to act on or too late to matter.
Send an all-clear. This is the one people skip and it's the most important. A weekly digest that says everything is healthy means silence is meaningful. If the digest doesn't arrive, the monitor itself is down, and that's a signal. Without it, "no alerts" is indistinguishable from "monitoring quietly died six weeks ago."
Put together, the job is: check the cert the server actually serves, validate the full chain, cover every TLS port and the domain registration behind it, watch CT for surprises but never for expiry, and tune the alerting so a human still reads it on the day it counts.
That's the whole discipline. CertPost is built around exactly this checklist if you'd rather not assemble it from cron jobs and openssl scripts, and the first three certs are free to try it on whatever keeps you up at night.