Expired certificates are one of the most embarrassing outages in operations, because they are entirely predictable. The expiry date is printed on the certificate. Yet they keep happening, usually not because nobody automated renewal, but because the automation failed quietly and nobody was watching.

Why Short Lifetimes Make Automation Mandatory

Certificate lifetimes have trended shorter over the years, and automated issuance through the ACME protocol, which is what Let’s Encrypt and several other authorities use, is now common. Short lifetimes are good for security, since a compromised key has a limited useful window, but they remove any chance of managing renewals by calendar reminder. Check your certificate authority’s current documentation for the lifetime and renewal guidance that apply to you.

The goal is not merely “renewal is automated.” It is “I will be told promptly if renewal stops working, well before anything expires.”

How Automated Renewal Typically Works

An ACME client such as certbot, acme.sh, or a built-in feature of your web server or proxy follows a loop:

1. A scheduler (cron, a systemd timer, or the server itself) wakes the client regularly.
2. The client checks the remaining lifetime of each certificate and, if it is within the renewal window, begins renewal.
3. The CA issues a challenge to prove you control the domain. The two common types are an HTTP challenge, where the CA fetches a file from your site over port 80, and a DNS challenge, where you publish a specific DNS record. Wildcard certificates generally require the DNS method.
4. On success, the new certificate and key are saved.
5. A deploy hook reloads the service so it starts using the new certificate. Forgetting this step is a classic cause of outages: the file on disk is fresh, but the running process still serves the old one.

Every step is a place to fail.

The Most Common Failure Modes

• The scheduler stopped or was never enabled. A timer disabled during a system rebuild, a cron entry lost during migration.
• Port 80 blocked, after a firewall change, or redirected in a way that breaks the HTTP challenge.
• DNS challenge credentials expired or were rotated, so the client can no longer publish the record.
• The domain no longer points at this server, after a migration, so the challenge goes elsewhere.
• The reload hook is missing or failing, leaving the service on the old certificate.
• Rate limits reached after repeated failed attempts or heavy testing; use the CA’s staging environment for experiments.
• Multiple servers behind a load balancer, where only one holds the new certificate.
• Permissions on key files that prevent the service from reading the renewed material.

Test Renewal Before You Need It

Most ACME clients offer a dry run mode that performs the full process against a test environment without replacing your certificates. Run it right after setup, and again after any change to firewall rules, DNS, web server configuration or hosting. A passing dry run does not guarantee future success, but a failing one tells you exactly what to fix while you are not under pressure.

Also verify that the deploy hook works: after a real or forced renewal, check the certificate actually served on the network, not the file on disk.

Monitor the Outcome, Not the Process

The most reliable detection looks at what users see. A check from outside connects to your domain over TLS, reads the presented certificate’s expiry date and alerts when fewer than a set number of days remain. Choose an alert threshold comfortably inside the renewal window: if renewals normally happen with a month to spare, an alert at two weeks means renewal has already failed at least once and you have time to fix it in working hours.

Layer your checks:

Check	What it catches	Alert timing
External TLS expiry probe	Any cause of non-renewal, from the user’s viewpoint	Well before expiry, in working hours
Renewal job status or last-success marker	Scheduler and client failures	Soon after a missed run
Dry-run renewal in CI or on a schedule	Configuration drift (firewall, DNS)	Before it affects a real renewal
Inventory of all certificates	Forgotten domains and internal services	Periodic review

Do not rely only on emails from the CA about upcoming expiry. They go to a contact address that may be unmonitored, and some authorities have changed or limited such notices; confirm current behavior in their documentation.

Do Not Forget the Forgotten Certificates

The certificate that expires and causes the outage is often not the main website. It is the internal admin tool, the mail server, the database client certificate, the API behind a partner integration. Build an inventory: every hostname and service that presents a certificate, where it is issued, how it is renewed and who owns it. Scanning your own networks and DNS records for TLS endpoints can reveal ones you forgot.

A Realistic Example

Suppose a team migrates their site to a new server and carefully copies everything, but the ACME client’s systemd timer is not enabled on the new machine. The existing certificate has a few weeks left, so nothing seems wrong. Their external expiry probe, set to alert at two weeks remaining, fires while the certificate is still valid. The administrator finds the timer disabled, enables it, runs a dry run that passes, forces a renewal and confirms the new expiry date from outside. In the postmortem they add the timer check and the dry run to the migration checklist, so the failure cannot recur silently.

Frequently Asked Questions

How early should I renew a certificate? Follow your CA’s and client’s recommended renewal window, which typically leaves ample margin. Early renewal gives you time to fix problems before expiry.

Why does the browser show the old certificate after a successful renewal? The service probably has not reloaded. A deploy hook that reloads the web server or proxy after renewal is usually required.

Do I need a DNS challenge? For wildcard certificates, generally yes. For single hostnames reachable on port 80, the HTTP challenge is simpler. Consider DNS challenges for servers not publicly reachable, with carefully scoped credentials.

Can I test renewal without affecting my live certificate? Most clients have a dry-run option that uses the CA’s staging environment. Use it after any change to networking, DNS or server configuration.

What should I monitor? The certificate presented to the outside world, with an alert threshold well before expiry, plus the renewal job’s last successful run.

Next Step

Add an external expiry check for every public hostname you run, set to alert at a threshold inside your normal renewal window, and run a renewal dry run on each server this week.