Certificate Expiry: Building a Process That Does Not Fail
Automated certificate renewal removed the recurring manual task and replaced it with a subtler one: confirming that the automation is still running. A renewal process that has quietly stopped looks exactly like one that is working, right up until the last valid day. Every practice below exists to close that gap.
Check the endpoint, not the certificate store
Renewal and deployment are separate steps, and only the second one is visible to your users. A certificate can renew perfectly in your client and never reach the load balancer, or reach three of four servers and leave one serving the old one to a quarter of traffic. Verifying against your issuing system answers the wrong question. Connect to the live endpoint — every endpoint — and read what it actually presents.
Enumerate every hostname, including the ones nobody mentions
The certificate that expires is never the one on your main site, because that one is watched. It is the API subdomain, the staging environment that turned out to be load-bearing, the admin interface on a non-standard port, or the hostname on a certificate covering names that were added years ago. Build the list from what is actually resolving and serving rather than from documentation, then check all of it.
Certificate Transparency logs are useful here precisely because they are not your inventory: they record every publicly trusted certificate issued for your domain, including ones a different team obtained from a different provider without telling anyone.
Stage the alerts
A single threshold produces either premature noise or a genuine emergency depending on where you set it. Thirty days is a calendar entry, fourteen is a ticket, seven is an escalation, and treating all three the same discards the information. The staged approach also survives someone acknowledging the first alert and forgetting — which is the normal failure of a single reminder.
Watch the chain, not just the expiry date
A valid certificate served with an incomplete chain fails for clients that do not already hold the intermediate — typically server-to-server integrations rather than browsers, which means the site works and an integration breaks. Certificate authorities reissue intermediates and change hierarchies, and renewal can quietly alter which chain gets served. Capture the presented chain alongside the expiry date so a change is visible.
Check the things that block renewal
Renewal fails for reasons that have nothing to do with certificates. A CAA record that names an authority you no longer use will block issuance while producing no symptom until the current certificate lapses. A DNS challenge that stopped resolving, credentials rotated out from under the client, a challenge path now returning 404 behind a new proxy rule — all of these fail silently and on a schedule you cannot see.
The useful move is to monitor the preconditions together with the expiry. A certificate at forty days with a CAA record that forbids its issuer is an outage already scheduled, and only the combination reveals it.
Treat a shortening renewal window as a failure
On a healthy host, remaining validity sawtooths — it climbs on each renewal and declines between them. On a broken one it simply declines in a straight line. That shape is visible weeks before expiry, but only if something is recording it. Alerting on the trend rather than only on the threshold buys you the earliest possible warning, which for certificates is the entire game.
Tools used in this playbook
For the underlying concepts rather than this procedure, NetTests.NET covers the topic in more depth in its guide.