What actually happens when an SSL certificate expires?
Every visitor gets a full-page interstitial they must click through. The site is not slow or degraded - it is unreachable to anyone who trusts their browser.
By Sapun Lamichhane · Arcetis
Every visitor gets a full-page interstitial they have to click through, and most will not. The server is healthy, the site is fine, and in commercial terms it is a total outage - which is what makes certificate expiry unusual: no gradual degradation, no partial failure, just a cliff.
Why do certificates expire if renewal is automated?
Because renewal has two steps and automation usually covers one. The ACME client obtains a new certificate and writes it to disk; the web server keeps serving the old one from memory until it is reloaded. A renewal hook that fails silently leaves you with a valid certificate on disk and an expired one being served - and every monitoring check that looks at the files says everything is fine.
The other common cause is scope. Automation renews the certificate it knows about. A subdomain added later, a load balancer with its own certificate, or an origin behind a CDN that terminates TLS separately - each is a place a certificate can quietly go unmanaged.
What else breaks besides expiry?
- Hostname mismatch. A certificate issued for `example.com` does not cover `www.example.com` unless the www form is listed in the subject alternative names. Both forms need to work, because both get linked.
- A missing intermediate. The certificate is valid and the server does not send the chain that proves it. Desktop browsers often recover by fetching the missing link; mobile browsers frequently do not, so the site fails only on phones.
- A deprecated protocol. TLS 1.0 and 1.1 were formally deprecated in 2021 and are refused or warned on by current browsers.
- A weak cipher suite. RC4, 3DES and export-grade suites all have published attacks and should not be negotiable.
How do I check it properly?
By opening a real TLS connection rather than reading headers. A handshake reports the negotiated protocol and cipher, and the leaf certificate's issuer, validity window, days remaining and subject alternative names - none of which any HTTP header exposes.
One subtlety worth knowing when building or choosing a checker: it must not abort on an untrusted chain. Refusing to continue returns nothing for exactly the sites worth reporting on - the expired, the self-signed, the ones missing an intermediate. The connection should complete and the failure reason should be recorded.
What should I monitor?
Days remaining, checked from outside your network against the hostname visitors actually use. Not the file on disk, and not from inside the VPC where a different certificate may be terminating. The SSL checker on this site does exactly that and reports the days remaining alongside the protocol, cipher and covered hostnames.