Certificate Lifecycle Management (CLM)

Certificate lifecycle management covers every stage of a certificate's life: discovery (knowing which certificates exist and where), request and issuance, deployment to servers, load balancers and CDNs, monitoring for expiry and misconfiguration, renewal with key rotation, and finally revocation and cleanup. Tooling ranges from a scheduled job running an ACME client to commercial platforms that inventory thousands of certificates across clouds.

Why it matters

Expired certificates are a recurring cause of outages, and shrinking lifetimes make manual processes untenable: the public maximum is 200 days as of November 2026, falling to 100 days in 2027 and 47 days in 2029. Reminder emails cannot be relied on either, since Let's Encrypt ended expiration emails on 2025-06-04. Good CLM automates renewal, supports ACME Renewal Information (ARI, RFC 9773) so a CA can ask clients to renew early, watches Certificate Transparency logs for certificates you did not expect, and checks the certificate actually served rather than the file on disk.

Example

certbot renew --dry-run
systemctl list-timers | grep certbot

The first command tests renewal end to end; the second confirms a scheduler actually runs it.

Common misconceptions

• Auto-renewal means the job is done. The new certificate must also be deployed and the server reloaded; many outages come from renewed files that nginx never loaded.
• Calendar reminders are enough. With 47-day certificates ahead, a missed manual step every few weeks is inevitable; automate instead.
• CLM is only for large enterprises. Even one site with a CDN, a load balancer and an API server has several places where a certificate can silently expire.