How to Monitor SSL Certificate Expiration

An expired TLS certificate takes a site from "working" to "browsers refuse to connect" instantly, with no gradual degradation to warn you first. It's also one of the most avoidable outages in web operations, because the expiration date is public information, known well in advance, and doesn't change unexpectedly.

Why this keeps happening anyway

Certificate expiry outages are almost always a process failure, not a technical surprise. The two most common patterns: a certificate that was set up once by someone who has since left, with no one else aware it needs renewal; and automated renewal (via a tool like Let's Encrypt's ACME protocol) that silently stopped working weeks or months before the actual expiry — a cron job that stopped firing, a renewal script broken by an unrelated server change, or a DNS validation step failing after a provider migration.

What "monitoring expiration" actually means

The minimum useful check is straightforward: connect to the server, retrieve the certificate actually being served, and read its expiry date — not the expiry date of whatever certificate is sitting in a file somewhere, since those can drift apart (a renewed certificate that was never actually deployed to the server is a real, common failure mode).

A more complete check also verifies:

  • The full chain, not just the leaf certificate. An expired or missing intermediate certificate breaks trust even when the leaf certificate itself is valid.
  • OCSP/revocation status — a certificate can be valid by date but revoked, which some clients check and others don't.
  • Every domain and subdomain actually in use — a wildcard certificate covering *.example.com doesn't cover example.com itself, and a forgotten subdomain on a separate certificate is a common gap.

How much advance warning is actually useful

A single alert the day before expiry gives no real time to fix a broken renewal process. A more useful pattern is a graduated warning schedule — for example at 30 days, 14 days, and 3 days before expiry — so a broken automated renewal has multiple chances to be caught and manually fixed before it becomes an outage, and the urgency escalates as the deadline actually approaches.

Certificate Transparency logs as a discovery tool

Every publicly trusted certificate is required to be logged in Certificate Transparency logs, which makes them searchable — useful not just for monitoring certificates you know about, but for discovering ones you didn't know existed: certificates issued for a subdomain you forgot about, or unexpectedly, a certificate issued for your domain that you didn't request at all, which is itself a security-relevant signal worth acting on.

Frequently Asked Questions

If I use automated renewal, do I still need to monitor expiration?

Yes — automated renewal fails silently more often than people expect (broken cron jobs, failed DNS validation after a provider change), and the only way to catch that before it becomes an outage is monitoring the actual served certificate, independent of whether renewal "should" have run.

Does checking the certificate file on the server tell me what's actually being served?

Not reliably — a renewed certificate that was never deployed or reloaded into the running web server process is a common gap. Checking the live TLS handshake, not just a file on disk, is what actually reflects what visitors experience.

What's the difference between certificate expiry and certificate revocation?

Expiry is a scheduled, known date the certificate stops being valid. Revocation is the certificate authority invalidating a certificate early, usually due to a compromised private key — checked via OCSP, a separate mechanism from the expiry date itself.

Stop checking this by hand

NetTests runs this kind of check on a schedule, stores historical results, and alerts your team the moment something changes.

Start monitoring free →
No credit card required  ·  Free plan available