Certificate Lifecycle Management
Issuing, deploying, monitoring and renewing certificates automatically, because manual tracking reliably produces outages.
Expired certificates remain one of the most common causes of self-inflicted outage, and they are notable for being entirely predictable — the failure date is known years in advance and it still happens, at large and sophisticated organisations, repeatedly.
The reason is that manual processes depend on a person remembering, and the interval is long enough that the person has usually changed roles. Certificate lifetimes have shortened substantially and continue to, which makes manual renewal untenable rather than merely unwise.
What a working practice contains: automated issuance and renewal through ACME or an internal certificate authority, with renewal well before expiry; an inventory of every certificate in the estate including the ones nobody registered, discovered by scanning rather than by asking; expiry monitoring with escalating alerts at thirty, fourteen and seven days; and automated deployment, since a renewed certificate sitting unbound in a store is not renewed in any useful sense.
The certificates that cause incidents are consistently the ones outside the main path: internal service-to-service certificates, client certificates for partner integrations, certificates embedded in mobile applications for pinning, code signing certificates, and the one on the load balancer that was configured manually four years ago by someone who has left.
The related design decision worth revisiting: certificate pinning in mobile clients trades a narrow security gain for a serious operational hazard, since a pinned certificate that expires or rotates unexpectedly bricks every installed application until users update.