A certificate is a deadline you forgot you set

Almost every security control fails quietly. A TLS certificate fails loudly, on a schedule, in front of every customer. The moment it expires, browsers stop trusting your site and throw a full-page interstitial that all but accuses you of being an attacker — and visitors, dutifully trained to fear exactly that screen, leave. It is a self-inflicted outage with a countdown timer, and the timer always seems to hit zero on a Saturday.

The maddening part is that it is entirely preventable. The certificate told you the exact date it would expire the day you installed it. The failure is never the cryptography; it is that nobody was watching the calendar for one certificate among the dozens an even small estate accumulates. This is an availability problem wearing a security costume, and it deserves the same standing watch you give uptime.

Why this is getting harder, fast

For years the answer was "set a yearly reminder," and for a single website that more or less worked. Two shifts have broken that habit:

  • Certificate lifetimes are collapsing. The industry is steadily shortening maximum validity from years toward a span measured in weeks. A renewal cadence you used to perform once a year becomes something you do constantly — far past what a human reminder can carry.
  • The estate sprawled. It is no longer one cert on one site. It is the marketing site, the app, a pile of subdomains, internal services, load balancers, mail, and APIs — each with its own certificate and its own expiry, and the forgotten ones are exactly where the attack surface hides a Saturday outage.

Shorter lifetimes plus more certificates equals a problem that manual tracking simply cannot survive. The only durable answers are automation and monitoring.

Automate the renewal, but do not trust it blindly

The first move is to stop renewing certificates by hand wherever you can. Automated issuance and renewal — the model most modern certificate authorities and platforms support — turns a recurring manual chore into a background process, the same way patch automation turns updates into something that happens without a human in the loop.

But "we automated it" is not the same as "it is working," and the gap between those two is where the Saturday outage lives. Automated renewal fails in ordinary, undramatic ways: a credential the renewal job uses expires, a DNS change breaks the validation challenge, a config reload silently does not pick up the new file. The automation can be broken for weeks and you will not know — until the old certificate expires and the automation that was supposed to have replaced it turns out to have stopped running. Automation removes the routine toil; it does not remove the need to watch.

You cannot watch what you have not inventoried

Monitoring expiry starts with knowing every certificate that exists, which is harder than it sounds because the dangerous ones are the ones nobody remembers. Build the list the same way you build any asset inventory:

  • Enumerate every certificate across the estate — public sites, every subdomain, internal services, mail, load balancers, APIs — and treat each as an asset with an owner and an expiry date.
  • Catch the forgotten subdomains, the same blind spot that enables subdomain takeover: a service stood up for a one-off project, still serving, its certificate quietly ticking down with nobody assigned to it.
  • Record more than the date. Issuer, key strength, what it protects, and who owns the renewal — so an expiry alert routes to a person instead of a void.

A certificate without a known owner is a future outage; the inventory is what gives every expiry a name attached to it.

Turn an approaching expiry into a tracked finding

With the inventory in place, expiry monitoring is straightforward: watch the dates and raise the alarm with enough runway to act. The discipline is to treat an approaching expiry as the same kind of object every other risk becomes — a finding with an owner, a severity, and a clock — rather than an email that scrolls past.

  • Alert with real lead time, not on the morning of, so renewal failures have room to be fixed before the outage instead of during it.
  • Rank by what the certificate protects, using the same exposure-first triage as everything else: the cert on your customer-facing app outranks one on an internal tool two people use.
  • Watch for the silent automation failure, not just the final date — a renewal job that has not run when it should have is the early warning that turns a near-miss into a non-event.
  • Capture the health of the estate as evidence. A clean report that every certificate is current, owned, and renewing feeds straight into continuous monitoring and the evidence collection an assessor reviewing your transport security will want to see.

One honest caveat: a platform can inventory your certificates, watch their expiry dates, catch a renewal that has silently stopped working, and turn an approaching deadline into a tracked finding with an owner — it organizes, watches, and proves the work. It does not issue or renew your certificates, configure your servers, make you compliant, or grant or guarantee any certification; the automation, the renewal, and the deployment are operational steps your team owns.

An expired certificate is the rare security failure that is loud, scheduled, and entirely your own doing — and as lifetimes shrink toward weeks, the yearly reminder that used to cover it is gone. Inventory every certificate, automate the renewal, then watch the dates and the automation itself so an approaching expiry becomes a tracked finding instead of a Saturday outage. The certificate told you the date. The only question is whether anything was listening.