An expired SSL certificate is a strange kind of outage. The server keeps running, the pages keep rendering, every uptime check keeps passing. But from the visitor's side, the site has effectively vanished behind a wall of warnings. This article covers what actually happens the moment a certificate expires, why it keeps happening even to teams with auto-renewal, and how to make sure it never happens on a site you are responsible for.
What visitors see the moment it expires
Modern browsers do not show a subtle padlock change. Chrome, Safari, Firefox and Edge all interrupt navigation with a full-screen warning: "Your connection is not private", complete with error codes like NET::ERR_CERT_DATE_INVALID. Getting past it takes multiple deliberate clicks through wording designed to make people turn back, and most people do turn back.
In practice an expired certificate cuts traffic to a small fraction of normal within minutes, and unlike a server outage, it does it while everything on your side looks healthy.
What it costs beyond the warning screen
- Trust. Visitors do not read error codes. They read "not private", "not secure", "attackers might be trying to steal your information", and they associate those words with your client's brand.
- Search visibility. HTTPS is a ranking signal, failed crawls and bounce spikes compound, and a site left broken for days can pick up "not secure" annotations in results.
- Everything that talks to the site. APIs, mobile apps, payment callbacks, webhooks and integrations validate certificates strictly and start failing with hard errors the second the certificate lapses. These failures are often noticed later than the browser warnings and are harder to trace.
Why certificates expire even with auto-renewal
"We have certbot, it renews itself" is where most expiry stories begin. Renewal automation is genuinely good now, but it fails silently in a long list of mundane ways:
- The renewal job stopped running. A cron entry lost in a server migration, a systemd timer disabled during debugging and never re-enabled.
- The DNS challenge broke. The domain moved DNS provider, and the renewal's DNS-01 challenge can no longer create its validation record.
- A CAA record blocks issuance. Someone hardened DNS and unintentionally forbade the certificate authority from issuing.
- The site moved, the renewal did not. Hosting migrated, but renewal still runs happily on the old server, renewing a certificate nothing serves.
- Renewed but never reloaded. The new certificate sits on disk while the web server or load balancer keeps serving the old one from memory.
- The forgotten edges. Wildcard gaps, staging subdomains, mail servers and API hosts that were never in the automation to begin with.
Notice the pattern: in every case the system reports success or says nothing at all. The only reliable signal is checking the certificate that is actually being served, from outside.
How to check a certificate right now
From any machine with OpenSSL, this prints the expiry date of the certificate a server is really serving:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddateIn a browser, click the padlock (or tune icon) in the address bar and open the certificate details. Check the expiry date, but also check the issued date: if it is months old on a 90-day certificate, your renewal automation is already broken and you are living on borrowed time.
How to never get caught again
- Inventory every certificate you are responsible for. Not just the main sites: subdomains, staging, API hosts, mail. Agencies typically find a third more certificates than they expected.
- Monitor from the outside. Check what each host actually serves, daily, from a system independent of the servers doing the renewing. Internal checks fail with the same root causes as the renewals they are supposed to watch.
- Alert early and repeatedly. 30, 14 and 7 days gives you time to fix a broken renewal calmly instead of during an incident. A certificate that has not renewed by 30 days out on a 90-day cycle is already a failure worth investigating.
- Verify after every migration. Hosting moves, DNS moves and load balancer changes are where renewal chains break. Add "confirm certificate renewal still works" to the migration checklist.
The agency multiplier
One certificate is easy. Fifty client sites across a mix of hosts, some with certbot, some behind Cloudflare, some on hosting-panel certificates, is certificate sprawl, and sprawl is where expiries hide. This is exactly the kind of check that should run automatically across the whole portfolio: TLDTrack monitors SSL expiry alongside uptime, DNS and security checks on every domain you add and alerts you weeks before anything lapses. It is one piece of the broader discipline covered in our guide on how to monitor client websites, and one of the clearest examples of why uptime monitoring alone is not enough.
