SSL Certificate Monitoring: What to Watch, and From Where

What shorter certificates changed

Shorter lifetimes did not make expiry more likely. They made renewal frequent enough that almost everyone automated it, and automation moved the failure. A certificate that renews twice a year without a human involved cannot be forgotten, but it can renew into a directory nobody reads, or renew correctly while the process serving it holds the old file open until the next restart.

The dates are set. The CA/Browser Forum's SC-081v3 ballot put the maximum validity of a public TLS certificate at 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The reuse period for domain validation shrinks alongside it, down to 10 days by 2029, so the validation step will run about as often as the issuance step. As of August 2026 the first of those three steps is already in force.

For monitoring, the useful way to read that schedule is as a shrinking margin for error. On a 398-day certificate a renewal that silently failed left you months to notice. On a 47-day certificate the same silent failure leaves weeks, and the second consecutive failure leaves nothing. Anything checked quarterly stops being a control and becomes a record of what used to be true.

There is a smaller change worth knowing about, because it will confuse a monitoring dashboard eventually. Certificates issued as short-lived under the Baseline Requirements, capped at seven days since 15 March 2026, are not required to carry revocation information at all, since they expire faster than a CRL or OCSP response would refresh. A check that flags "no revocation URL" as a fault will start crying wolf the day someone adopts them.

The four places you can watch from

A certificate can be observed from four positions, and the word "monitoring" gets applied to all of them without distinction. Your CA account knows what was issued. Certificate Transparency knows what any public CA issued for your names. The host knows what file it was given. Only a probe of the live endpoint knows what is being served right now.

Your CA account is an ordering record. It is authoritative about issuance and end dates, it covers certificates you bought and nothing else, and it has no idea what happened after you downloaded the files. It is the right place to answer "what do we own and when does it run out", and the wrong place to answer "is production healthy".

Certificate Transparency logs are a public, append-only record of publicly trusted issuance. Chrome will not accept a certificate that lacks signed certificate timestamps from qualified logs, which in practice means every public certificate for your domains appears in CT, usually within a few hours of issuance. That includes certificates ordered on a company card by a team you have never met, and certificates obtained by someone who should not have been able to obtain them. No other vantage point shows you either.

The file on the host is what configuration management sees. It is cheap to check, it covers internal and private-CA certificates that CT will never contain, and it lies in one specific way: a file is not a running service. The new certificate can sit on disk for a week while nginx serves the old one out of memory.

A probe of the live endpoint opens a TLS connection to a hostname and port and reads back the leaf and the chain that were actually presented. It is the only view that matches the visitor's experience, and it is the only one that catches a deployment that did not happen. Its weakness is scope: it sees the endpoints on its list and is serenely unaware of the rest. For a single hostname you can get this view immediately with the free SSL certificate checker, which reports the served chain, the SANs, the signature algorithm and the days remaining for whatever is answering on that port right now.

Two of these four, chosen so they disagree, beat four dashboards that all read from the same inventory. In practice that pairing is a live probe plus a CT feed: one tells you what you are serving, the other tells you what exists in your name.

Which failures each vantage point catches

Map real failures against the four positions and the gaps become obvious. The classic expiry, a certificate that ran out because nobody renewed it: is caught by all four, which is precisely why it has become rare. The failures that survive are the ones with a single mark in their row, and those are the ones worth designing around.

The highlighted row is the modern one. A renewal completes, the CA's records look perfect, CT shows a fresh certificate with 200 days left on it, the new file is sitting on the host, and the load balancer in front of it is still presenting the certificate it loaded at boot. Every inventory-based view reports success. Only something that actually connects notices, and it notices instantly, because the served certificate has the old serial number and the old end date.

The last row is the mirror image and catches people who did build a probe. A certificate covering both the web front end and the mail server gets renewed and redeployed on 443, where the probe watches; the SMTP listener on 465 keeps the old copy, because the deployment script only ever knew about the web server. The inventory views would have flagged it. The probe never looked.

What to alert on besides the end date

Days-to-expiry is one signal among several, and on its own it is the slowest of them. A certificate that failed to deploy is detectable the moment it fails, not thirty days before the old one runs out, and the difference between those two detections is the difference between a quiet fix and a weekend. Alert on the state you expect, and let expiry be the backstop.

The second row is the one to build first if you build only one. "This certificate is older than the renewal interval" is an alert that fires on the day automation breaks rather than weeks later, and it needs no integration with the tool doing the renewing, just the notBefore date from the endpoint and the number of days you expect between renewals.

Picking a threshold that survives 2027

Express warning thresholds as a share of the certificate's lifetime rather than a fixed number of days. Thirty days was a comfortable 7.5% cushion on a 398-day certificate. Against the 200-day maximum in force since 15 March 2026 it is 15%, against 100-day certificates it is 30%, and against 47-day certificates it is roughly two thirds of the certificate's entire life.

A workable pair of thresholds is a warning at about one third of the lifetime remaining and an escalation at one tenth. On today's 200-day certificates that is roughly 66 days and 20 days; on the 100-day certificates arriving in March 2027 it becomes about 33 and 10; on 47-day certificates it lands near 16 and 5. Written as fractions, the same rule carries through every step of the schedule without anyone editing a config file in a hurry.

One caveat on the escalation tier: it should be long enough to actually reissue. If your process involves organisation validation that can take a working day or two, a 5-day escalation on a 47-day certificate is tight, and the answer is to renew earlier rather than to alert later. Certificates that renew at two thirds of their life have two full attempts before anything is at risk, which is the real reason ACME clients renew so early.

If you are managing a handful of certificates rather than a fleet, the same arithmetic works without a monitoring stack, check the endpoint, then set an expiry reminder for that hostname at 30, 14 and 7 days and treat the earliest one as the date you act on.

It is not only port 443

Monitor every port that terminates TLS, not every website. The usual list runs well past the web server: SMTP on 25, 465 and 587, IMAP on 993, LDAPS on 636, database listeners, message brokers, VPN concentrators, printer and NAS admin pages, and the internal dashboards that nobody counts as production until they stop loading.

Two details decide whether the probe reports the truth. The first is name-based virtual hosting: a server can hold dozens of certificates and picks one based on the Server Name Indication extension in the client hello, so a probe that connects by IP address gets whatever the default virtual host is configured with, which is frequently not the certificate you meant to check. Always probe by hostname.

The second is protocols that start in the clear. SMTP on port 587 and IMAP on 143 negotiate TLS with STARTTLS after an initial plain exchange, so a probe that opens a raw TLS socket simply hangs or reports a handshake error. The check has to speak enough of the protocol to reach the upgrade, which most mature monitoring tools support and most quick scripts do not. A mail server certificate that never appears on a dashboard is usually this, not an oversight.

Build the list from DNS and from your load balancer configuration rather than from memory, and rebuild it on a schedule. The endpoints that cause incidents are the ones added after the monitoring was set up.

The chain, and certificates you did not order

Check the chain the server sends, not just the leaf it sends. A server is expected to present its leaf plus the intermediates needed to reach a trusted root, and when an intermediate goes missing after a renewal the result is the most confusing class of certificate incident: desktop browsers keep working from cached intermediates while Java clients, older Android devices and command-line tools fail on the identical host.

This happens more often than the failure deserves, because the two files are separate. A deployment that copies cert.pem and forgets chain.pem, or installs a leaf where the configuration expects a bundle, produces a host that tests fine from the engineer's laptop. Any check that validates the served chain from a clean trust store rather than a browser catches it on the first run.

Watching CT logs answers a different question: what exists in your name. Because publicly trusted certificates must be logged for Chrome to accept them, a search over your domains returns the complete public picture, and anything in it that your team did not order is worth a conversation the same day. Most hits are mundane, a marketing agency standing up a landing page, a cloud provider issuing automatically for a hostname you delegated. The point is that they are all visible, and none of them would appear in your CA account.

CT monitoring pairs naturally with a CAA record on your domain: the CAA record states which certificate authorities are allowed to issue for you, and the CT feed tells you whether anything got issued anyway. One is a control, the other is the audit of that control, and neither substitutes for the other.

Keeping the alerts worth reading

An expiry alert that fires every day for six weeks trains everyone to ignore expiry alerts, and it is the most common way certificate monitoring fails while appearing to work. The fix is not a longer threshold or a quieter channel. It is making each alert correspond to an action that someone can take once.

Three habits do most of the work. Alert on the transition rather than the state, so crossing the threshold notifies once instead of every polling cycle. Group by certificate rather than by endpoint, because one wildcard on forty hosts is one renewal and should be one ticket. And separate "needs attention this month" from "is broken now" into different destinations, the first belongs in a weekly digest, the second belongs wherever your on-call actually looks.

It is also worth alerting when a check stops reporting. A probe that silently dies looks exactly like a fleet with no problems, and the certificate it was watching expires on schedule regardless. A heartbeat on the monitoring itself is a small amount of work that closes the one gap nothing else covers.

A setup that fits on one page

Most teams need five things, and none of them require a certificate lifecycle platform to start. The order below is deliberate: each step closes a failure the previous one could not see, so stopping after any of them still leaves you better off than before.

1. Build the endpoint list from DNS and load balancer config, including non-web ports. Rebuild it monthly. An endpoint that is not on the list is not monitored, whatever the dashboard says.
2. Probe every endpoint by hostname, hourly, and record the served leaf and chain. This single step covers deployment failures, chain breaks and name mismatches at once.
3. Alert on age, not only on expiry. If a certificate is older than your renewal interval, the automation has already failed, and you have the full remaining lifetime to fix it calmly.
4. Set expiry thresholds as fractions, warn near a third of the lifetime, escalate near a tenth. They then survive March 2027 and March 2029 without an edit.
5. Watch Certificate Transparency for your domains and pair it with a CAA record. This is the only step that finds certificates you never ordered, and it costs nothing to run.

Add a heartbeat on the probe itself and the set is complete. It will not manage renewals for you, and it is not meant to, its job is to tell you, quickly and in plain terms, when something you believed was true stopped being true.

FAQ