An expired TLS certificate is the most preventable outage in existence. The expiry date is known months in advance, to the second. And yet expired certificates still take down big, well-staffed services every year - payment providers, government portals, even monitoring companies. If it happens to them, the safe assumption is that it can happen to you.
Here is why it keeps happening, and the checklist that reliably prevents it.
Why certificates still expire in the age of automation
Let's Encrypt and ACME made renewal automatic - and automation made people stop looking. The failure modes simply moved one level up:
The renewal job died silently. The cron entry was on a server that got rebuilt. The systemd timer was disabled during debugging and never re-enabled. Certbot renewed happily for a year, then a package update changed the plugin name. Automation that isn't monitored is just a delayed outage.
The challenge stopped working. HTTP-01 challenges break when a redirect rule, firewall change or CDN starts intercepting /.well-known/acme-challenge/. DNS-01 challenges break when you migrate DNS providers and the API token in your renewal config still points at the old one. Nothing fails on migration day - it fails 60–89 days later, when the next renewal quietly errors.
The certificate renewed, but the service didn't reload. This one is beautifully cruel: the new certificate sits on disk, valid and shiny, while nginx or HAProxy keeps serving the old one from memory until someone reloads it. Every "but certbot says it renewed!" incident we have seen was this.
A hostname fell through the cracks. The main site renews fine; api.example.com was issued manually 11 months ago by someone who left. Wildcards help but don't cover apex + subdomain mixes, and separate services (mail, status page, admin panels) often carry their own certs.
The edge and the origin diverge. With a CDN, users see the CDN's certificate - which the CDN manages - while the origin certificate expires unnoticed until the CDN suddenly can't talk to your origin over TLS.
The domain itself expired. Not strictly a certificate problem, but the failure looks similar and the cause is the same: a calendar event nobody owned. Domain expiry is worse - grace periods are short, and recovery can involve auction sites.
What expiry actually does
The moment a certificate lapses, browsers show a full-page interstitial warning - most visitors will not click through, and they shouldn't. API clients are stricter: almost every HTTP library fails hard on an invalid certificate, so machine-to-machine integrations stop instantly. Mobile apps pinned to your API die with them. The reputational cost outlasts the outage: "their security certificate was expired" is how customers remember it.
The checklist
Work through this once, then let monitoring keep it true.
1. Inventory every hostname that serves TLS. Apex, www, api, staging environments that customers somehow found, the status page, the mail host. If it has an A/AAAA/CNAME record and answers on 443, it's on the list.
2. Know the renewal mechanism for each one. ACME with HTTP-01? DNS-01? Bought from a CA with manual renewal? Managed by the CDN or load balancer? Write it down next to the hostname. The dangerous certs are the ones where the answer is "not sure".
*3. Verify what is being served, not what is on disk.* The only test that matters is the client's view:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
Run it per hostname - SNI (-servername) matters, because one IP can serve many certificates.
4. Reload after renewal - automatically. Your renewal hook must end with a service reload (systemctl reload nginx or equivalent), and ideally with a post-check that the served certificate's serial actually changed.
5. Check the whole chain. Intermediate certificates expire too, and an incomplete chain fails only on some clients (older Androids are the classic victims). Test with strict clients, not just Chrome, which is famously forgiving about fetching missing intermediates.
6. Monitor expiry with a 14-day threshold. Three days of warning is not enough when renewal is broken and the person who understands it is on holiday. Fourteen days converts an emergency into a ticket. Alert again as the deadline approaches if nothing changed.
7. Monitor the domain expiry separately. Registrars send renewal emails to whichever address was current five years ago. An external check against registration data (RDAP) with the same 14-day threshold catches it regardless of where those emails go.
8. Never rely on a calendar event. Calendars remind the person who created the event, at a company they may no longer work for, about infrastructure that may have changed. Monitoring checks reality every day; calendars check assumptions once.
The 2 a.m. call, prevented
Every certificate incident follows the same script: surprise, disbelief ("but it auto-renews!"), a scramble to find credentials, and a fix that takes ten minutes once the right person is awake. The entire drama exists only because the first warning arrived from an angry customer instead of from a monitor two weeks earlier.
For what it's worth, this is exactly why SiteBot24 checks certificate and domain expiry daily on every monitored site and starts alerting 14 days out - the threshold that, in our experience, turns night-time incidents into Tuesday-morning chores.