Cloud Platform
Every organisation that has had a certificate expire on them says the same thing afterwards: we knew when it expired. The date was never the problem. The problem is that knowing an expiry date and having a process that acts on it are different things, and only one of them prevents an outage.
What a certificate actually does
A TLS certificate does two jobs. It proves that the server your visitor reached is the server they intended to reach, and it establishes the encrypted channel between them. When it expires, browsers don't degrade gracefully — they show a full-page warning that most users read as "this site has been hacked."
That's why expiry is disproportionately damaging. A slow site loses some visitors. An expired certificate loses nearly all of them, and does reputational damage that outlasts the fix.
Why it keeps happening
Ownership is ambiguous
The certificate was bought by procurement, installed by a contractor, and renews to an email alias nobody monitors. Everyone assumes someone else is watching.
The inventory is incomplete
You know about the main website. You've forgotten the staging environment, the mail gateway, the internal API, the load balancer, and the appliance a vendor installed in 2021 that quietly serves an admin portal over HTTPS.
Renewal isn't the same as deployment
This one catches experienced teams. The certificate renewed automatically. It was issued correctly. Nobody deployed it to the three servers behind the load balancer, or restarted the service that only reads its certificate at startup.
Validity periods keep shrinking
Maximum certificate lifetimes have been falling steadily across the industry. A manual process that was tolerable when certificates lasted years becomes a permanent low-grade emergency when they last months. Any process that depends on someone remembering will fail; the only question is when.
The chain matters too. A significant share of "expired certificate" incidents are actually incomplete chain incidents — the leaf certificate is valid, but an intermediate is missing or stale. It works in the browser you tested with, and fails in the mobile app, the API client, or the payment gateway that has a stricter trust store.
What a working process looks like
- Inventory everything, including the things nobody owns. Scan your address space for anything listening on 443. You will find certificates you did not know existed. This is normal and it's the whole point of the exercise.
- Automate issuance and deployment together. Automating renewal without automating deployment just moves the failure one step later.
- Monitor from the outside. Check the certificate the way a visitor sees it, from outside your network, including the full chain. Internal checks miss chain problems constantly.
- Alert on days remaining, escalating. Thirty days is informational. Fourteen days is a ticket. Seven days is a phone call to a named person.
- Name an owner per certificate. A person, not a team alias. Teams don't renew certificates; people do.
The question to ask yourself today
Not "when does our certificate expire" — you know that. Ask instead: if the person who normally handles renewals were unavailable for a month, would anything expire? And would we find out from our monitoring, or from a customer?
If the honest answer to the second question is "from a customer," the certificate isn't the thing that needs fixing.
