An expired certificate doesn't slow your site down or make it look a bit off. It stops most visitors dead at a full-page warning, and it breaks every script, app and webhook that talks to you over HTTPS. The fix is usually quick once you know which of a handful of causes you're dealing with, and the lasting fix is making sure it can't quietly happen again.
Every major browser treats an expired certificate as a hard error, not a small warning icon.
NET::ERR_CERT_DATE_INVALID.SEC_ERROR_EXPIRED_CERTIFICATE.Visitors can sometimes click through an "Advanced" link, but most won't, and they shouldn't be trained to. If your site sends an HSTS header, browsers that have seen it remove the click-through option entirely. The site is simply unreachable for them until you fix it.
Machines are less forgiving still. curl fails with curl: (60) SSL certificate problem: certificate has expired, and so do most HTTP libraries, payment callbacks, monitoring probes and mobile apps. Often the first sign isn't a visitor complaint at all. It's a queue of failed webhooks somewhere else.
The date error has two possible causes: the certificate really has expired, or the visitor's clock is wrong. A laptop with a dead CMOS battery or a phone set years in the past will show the same ERR_CERT_DATE_INVALID on every HTTPS site it visits. If one person sees the error and nobody else does, check their clock first.
To check the certificate itself, run the domain through our SSL certificate checker. It shows the expiry date, days remaining and whether the certificate is trusted. From a terminal:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesThe notAfter line is the expiry, in UTC. Don't leave out -servername. Without it, a server hosting several sites may hand you a different site's certificate and you'll end up debugging the wrong one.
Check every name people actually use. example.com and www.example.com are often served by separate certificates, or even separate servers. If you have IPv4 and IPv6 addresses, they can point at different machines too, so one path can be fixed while the other is still broken.
What you do depends on where the certificate came from.
Let's Encrypt with certbot. Try a renewal and watch the output:
sudo certbot renew
sudo systemctl reload nginxSwap in apache2 or whatever web server you run. If certbot renew fails, the error message usually names the problem (more on common ones below). If it succeeds and the site still shows the old date, the web server hasn't been reloaded. It's still holding the old certificate in memory.
A paid certificate. Buy the renewal (or reissue it if you already have), then install the new certificate with its intermediate chain. Installing only the leaf is a classic way to swap an expiry error for a chain error that shows up in some clients and not others.
Hosting panel or managed platform. Look for a reissue or "force renew" button. When those fail, it's nearly always because the domain's DNS no longer points at that host, so the host can't prove you control it.
Behind a CDN or proxy. Remember that there are two certificates: the one the CDN shows visitors and the one on your origin server. If the edge certificate is fine but the origin's has expired and the CDN is set to validate it strictly, visitors get the CDN's own error page instead (Cloudflare's is error 526). Renew the origin.
Automation fails quietly, so work through the usual suspects:
systemctl list-timers | grep -i certbot, or look in cron.Run sudo certbot renew --dry-run after any fix. It tests the whole renewal path against the staging servers without issuing a real certificate.
Manual renewal was just about tolerable when certificates lasted a year or more. It isn't now. Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime for publicly trusted certificates dropped from 398 days to 200 days for certificates issued from 15 March 2026. It falls to 100 days from 15 March 2027 and to 47 days from 15 March 2029. As of 2026, anything that depends on someone remembering will fail sooner or later.
Three things cover almost everyone:
openssl x509 -checkend makes a simple cron check possible:openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -checkend 1209600 || echo "expires within 14 days"-starttls smtp and connect to port 25 instead of 443.The connection is still encrypted, but the browser can no longer vouch for who's on the other end, so it treats the site as untrusted. The practical harm is that visitors either leave or learn to click past warnings, which is a habit attackers rely on. Fix it rather than telling people to proceed.
Usually one of three things: the laptop's clock is wrong, the two devices are reaching different servers (IPv6 on one, IPv4 on the other is common), or one of them has an old page cached. Compare the certificate details each device shows. If the expiry dates differ, you have more than one server to fix.
Let's Encrypt suggests renewing when about a third of the lifetime remains, which is around 30 days for a 90-day certificate, and certbot's default follows the same rule. Alert yourself if a certificate gets within a week or two of expiry, because by then the automation has already failed at least once.
Yes. Every certificate in the chain has its own expiry date, and a chain that ends in an expired root fails on devices that don't know a newer path. Our guide on how to read an SSL certificate shows how to inspect each link in the chain.
0 comments
No comments yet. Be the first.