Certificate lifecycle management: the outage you schedule yourself

Certificate expiry is the rare failure that is entirely predictable, entirely preventable, and still takes down major services regularly. The date is known years in advance. What fails is the process that was supposed to act on it.

Why manual tracking always fails eventually

It works until one of these happens, and one of them always does: the person who maintained the spreadsheet leaves; a certificate is issued outside the normal process to solve something urgent; a service is deployed with a certificate nobody registered; the renewal reminder goes to a mailbox that no longer exists; or the renewal happens but the new certificate is not deployed everywhere the old one was.

That last one deserves attention. Renewal is not deployment. A certificate replaced on the load balancer but not on the origin servers, or on three of four nodes, produces an outage that looks baffling because "we renewed it".

What the inventory must capture

• Every certificate, including internal and non-production ones.
• Expiry date, issuer and key algorithm.
• Every location it is deployed — not just the primary service. This is the field most inventories omit and most outages hinge on.
• A named owner, and a fallback owner.
• Renewal method: automated or manual, and if manual, why.
• What breaks if it expires — so priority is obvious under pressure.

Build it from discovery rather than from memory. Scan your external estate, query your load balancers and cloud services, and check internal CAs. Organisations consistently find certificates nobody knew existed, and those are the ones that expire.

Automate, because lifetimes are shrinking

Public certificate lifetimes have been contracting for years and the direction of travel is clear. Manual renewal at scale becomes untenable well before the theoretical limit — the practical point at which it breaks is when renewal frequency exceeds the attention your team can reliably give it.

Automation via ACME is the standard answer for public certificates and is well supported. For internal PKI, use tooling that can issue and rotate without human steps. Treat any manual renewal as a documented exception with a compensating control — usually a monitored alert with a long lead time and a named owner — rather than as the normal case.

Monitoring that actually helps

• Alert at multiple horizons — 60, 30 and 7 days — not once.
• Alert to a team destination, never an individual mailbox.
• Monitor the certificate served by the endpoint, externally, rather than the one in your records. This catches the renewed-but-not-deployed case, which internal tracking cannot.
• Include internal services. Internal expiry breaks service-to-service authentication and is harder to diagnose because it is less visible.

Beyond expiry

Lifecycle management also covers revocation when a key is compromised, rotation of the underlying keys rather than reissuing on the same key indefinitely, retiring weak algorithms, and knowing where every private key is stored and who can reach it. The inventory you build for expiry is the same inventory you will need for a post-quantum migration — which is a reason to build it properly now.

Key takeaways

• Renewal is not deployment — track every location, not just the service.
• Build the inventory from discovery; the unknown certificates are the ones that expire.
• Alert at multiple horizons, to a team, and verify externally.
• The same inventory underpins any future cryptographic migration.