Why Certificates Still Expire in Production

The false comfort of automation

Most teams install an ACME client, watch it renew successfully once, and mentally file certificates under "solved". The problem is that renewal is a pipeline with several independent steps, and the automation only owns the first one.

A certificate can be issued perfectly and still never reach the process that serves traffic.

• Renewed but not reloadedThe new certificate is on disk. The web server has not been signalled to reload, so it keeps serving the old one from memory until it restarts — which might be after expiry.
• Renewed on one node onlyIn a pool of servers, one missed the deploy. A fraction of your traffic gets an expired certificate, so the problem is intermittent and hard to reproduce.
• Validation silently brokeA DNS provider migration or a firewall rule change invalidated the challenge method months ago. Renewal has been failing quietly ever since.
• Terminated somewhere elseTLS is terminated at a CDN or load balancer that has its own certificate lifecycle, entirely separate from the one your ACME client manages.

Chain problems look like nothing until they do not

A certificate chain needs the leaf plus every intermediate up to a trusted root. If an intermediate is missing, desktop browsers frequently paper over it using cached copies from other sites — so it works fine when you check.

Stricter clients do not. curl, mobile SDKs, server-to-server API calls, and payment gateways will reject the connection outright. The result is a site that appears healthy in a browser while your integrations fail.

Shortening lifetimes raise the stakes

Certificate validity windows have been shrinking steadily across the industry. Shorter lifetimes are better for security, but they mean renewal happens more often, and every renewal is another chance for the pipeline to break.

Renewal processes that were reliable at longer intervals need revisiting as windows narrow. Manual renewal, in particular, stops being viable.

A staged warning ladder

One warning is not enough, and constant warnings become noise. Escalating urgency as the deadline approaches is the pattern that works.

• 30 days — informational. Email and a dashboard flag. Renewal should already be scheduled.
• 14 days — something is wrong with automation. Investigate now.
• 7 days — a real alert to the team channel. Manual intervention likely needed.
• 1 day — treat as an active incident, because it is about to become one.

The reason the early warnings matter is that renewal problems are rarely fixed in minutes. A broken DNS challenge or a provider account issue can take days to resolve.