An expiring certificate breaks one service. An expiring CA breaks all of them.
Certificate expiry is a solved problem, and it has been for years. ACME, cert-manager, a dozen commercial tools — pick one, point it at your endpoints, and leaf certificates renew themselves while you sleep.
So why does an organisation with all of that still go down because something expired?
Because the thing that expired was not a leaf.
The asymmetry
A leaf certificate serves one thing. When it expires, that thing breaks, someone is paged, and fifteen minutes later a renewal has run. It is a bad afternoon.
An issuing CA signs everything beneath it. When it expires, every certificate it ever signed stops validating at once — including the ones your automation renewed perfectly last night, because a freshly issued certificate under an expired issuer is just as dead as a stale one.
And here is the part that makes it worse: your renewal automation cannot fix it. Requesting a new certificate from an expired CA does not work. In HashiCorp Vault's PKI engine, for instance, the mount refuses to sign past its issuer's expiry rather than silently truncating the validity — which is the correct behaviour, and which means every renewal through that mount fails at the same moment.
No amount of certificate automation helps you after the authority has expired. That is the whole problem in one sentence.
This is not hypothetical
In December 2018, an expired certificate inside a telecoms vendor's network management software took 4G data and SMS off more than 32 million subscribers in the UK alone, with the wider incident reaching eleven countries, for most of a day.
Nobody was careless. There was no missed alert on a dashboard, because the thing that expired was not on anyone's dashboard. That is the part worth sitting with.
Why nobody watches it
Three reasons, and they compound.
- It is rare. An issuing CA might have a ten-year life. Nobody builds a routine around an event that happens twice per career.
- It is invisible to your tooling. Certificate monitoring watches endpoints. Your issuing CA is not an endpoint — it is a key in an HSM, a mount in Vault, a resource in a cloud CA service. Nothing scans it because nothing serves it.
- The timeline defeats intuition. On a linear chart running to ten years, everything expiring inside the next quarter collapses into the first two percent of the width. The CA that is seven days out and the one that is nine years out are visually adjacent.
What actually helps
Put the authorities on the same clock as the certificates. Not a separate spreadsheet, not a calendar reminder someone set in 2019 and has since left the company — the same inventory, the same alerting path, the same screen.
Then fix the axis. A logarithmic time axis gives the next thirty days about a third of the display and compresses the safe years into the tail, which is the correct allocation of attention. Urgency becomes a position you can see rather than a number you have to read and mentally rank.
And plan the rotation before you need it. An issuing CA rotation is a project — new key, new certificate, cross-signing if you want continuity, a migration window for everything that pins. Discovering that at seven days' notice is how a planned event becomes an incident.
This is the problem I built CertPilot around. It watches authorities first and certificates second, for exactly the reason above.