Expired TLS certificate: a recovery runbook for the first hour

When a certificate has expired, issue a replacement, install it on every place that served the old one, reload the service, and verify from outside your network. Then find out why renewal failed, because the same cause usually threatens your other certificates. Do not tell users to click through warnings.

Step 1: confirm it is the certificate

Browsers report expiry with a clear error, but API clients often fail with vague messages such as a handshake failure. Check the certificate directly from a machine outside your network:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Look at the notAfter line. Compare it with the current time on that machine. A wrong clock on a client also produces expiry errors, so check that too.

Step 2: list every place that serves the name

One hostname often lives in several places: the load balancer, a CDN, an ingress controller, a mail server, an internal service that does mutual TLS, a device fleet that pins the certificate. Write the list before you start. Teams lose time when they fix the website and forget the API gateway.

If you do not know the list, use certificate transparency logs to find hostnames you have issued certificates for, then match them against your inventory. The post on finding your hostnames with certificate transparency shows the idea.

Step 3: issue and deploy

If you use an ACME client, run a forced renewal and read the error output. Common failures are a changed DNS record, a blocked validation path, a rate limit, a revoked API token for the DNS provider, or a renewal job that quietly stopped running.

If the automatic path is broken and you are short on time, issue a certificate by hand from your CA, install it, and fix automation afterwards. Make a note of the manual step in the incident log.

After installing, reload the service. Some servers read certificates only at start, so an updated file on disk changes nothing until reload. Then verify from outside and check the full chain, not just the leaf. A missing intermediate certificate produces errors for some clients and not others.

Step 4: tell people what happened

A short status update is enough: what customers saw, that it is fixed, and that you are checking for similar risks. Keep the technical detail for the postmortem.

Step 5: find the real cause

Expiry is a symptom. The cause is often one of these:

• Renewal ran only on one server, and that server was retired.
• The certificate was issued by hand years ago and nobody owned it.
• Alerts went to a shared mailbox nobody reads.
• The renewal job fails silently and nothing checks the result.

Let's Encrypt's integration guide gives useful targets for automation. It recommends checking renewal information for each certificate at least twice a day, and as a backstop renewing with about a third of the lifetime left. For its 90 day certificates, that is around 30 days of margin. It also says renewal failures should be treated as retryable, and that errors should reach the administrator in charge. Margin and loud failure are the two ideas to copy, whichever CA you use.

Lifetimes are also getting shorter. The CA/Browser Forum Baseline Requirements list maximum subscriber certificate validity of 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Manual renewal gets harder every step. See TLS certificate lifetimes of 200, 100 and 47 days.

Step 6: add a guard

• Monitor expiry from outside, per hostname, and alert at a margin larger than your slowest manual process.
• Alert on renewal job failure, not only on expiry.
• Give every certificate an owner.

For prevention in depth, use the certificate expiry outage prevention checklist.

Quick check

Sources

• Let's Encrypt: Integration guide
• CA/Browser Forum: Baseline Requirements

Last reviewed: 19 October 2026.