A certificate carries two dates: the moment it becomes valid and the moment it stops. One second after the second date, every browser refuses it. There is no grace period, no reduced warning, and no way for a visitor's browser to be told the certificate is "nearly fine".
The fix is to install a new certificate. What is worth understanding is how to do that quickly for the kind of certificate you have, and why the old one was allowed to lapse.
What visitors see
A full-page warning in place of the site. Chrome shows "Your connection is not private" with the code NET::ERR_CERT_DATE_INVALID. Firefox shows "Warning: Potential Security Risk Ahead" with SEC_ERROR_EXPIRED_CERTIFICATE. Safari says the connection is not private.
Most visitors leave. The page offers a route through, hidden behind an Advanced link, and almost nobody outside the industry takes it.
Two things make an expiry worse than it first appears:
- If the site sends an HSTS header, the bypass is removed. The browser has been told never to accept an insecure connection to that domain, so it offers no way to continue. The site is unreachable until the certificate is replaced.
- Everything that is not a browser fails silently. API clients, mobile apps, payment webhooks, monitoring checks and mail servers reject the certificate and report a connection error. There is no warning page for a machine to click through.
Confirm it is the certificate
The same warning page appears for several different faults, and only the small error code under the heading tells them apart.
Run the domain through the SSL Checker. The Expiry result states the date and how many days ago it passed. If it reports the certificate as valid with time remaining, the certificate is not the problem.
Check the device's clock first if only you see the error. A certificate is judged against the clock of the machine checking it. A computer, phone, printer or games console with the wrong date will report perfectly good certificates as expired or not yet valid, on many sites at once. If the warning appears on sites that are plainly working for everyone else, fix the date and time on the device.
If it is someone else's site, you cannot fix it. The site's owner has to replace the certificate. Telling them is the useful thing to do.
From a terminal, to see the dates directly:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
Renewing it now
Which of these applies depends on where the certificate came from. The Issuer shown by the SSL Checker tells you.
A free automated certificate
Let's Encrypt and similar authorities issue 90-day certificates that are meant to renew themselves. Force a renewal:
sudo certbot renew --force-renewal
Then reload the web server so it picks up the new file. If the renewal reports an error, that error is the reason the certificate expired in the first place — why Let's Encrypt renewal fails goes through the six usual causes.
A paid certificate
A bought certificate is not renewed by paying an invoice. Renewal means a new certificate is issued, and it has to be installed:
- Generate a new certificate signing request on the server.
- Submit it to the certificate authority and complete domain validation, by email, a DNS record or a file on the site.
- Download the new certificate and its intermediate certificates.
- Install both and reload the web server.
Step 3 is where a second outage is made. Installing the certificate without the intermediates produces a site that works on your desktop and fails on phones — an incomplete certificate chain.
A hosting control panel
Most panels have an SSL or security section with a button to issue or reissue a free certificate. If automatic issuing is switched on and the certificate expired anyway, the panel will usually say why: the commonest reason is that the domain's DNS no longer points at that host.
A managed platform or CDN
Website builders and CDNs issue and renew certificates themselves. An expiry here nearly always means the platform could no longer validate the domain, because a DNS record it depends on was changed or removed. Check the domain's connection status in the platform's settings, and compare the records it asks for against what the DNS Checker shows.
It was renewed and the error is still there
Three causes, in order of likelihood.
The server was not reloaded. A web server reads its certificate at start-up and keeps it in memory. The new file is on disk and the old certificate is still being served. Reload the server; a full restart is not normally needed.
Something in front of the server has its own copy. A load balancer, CDN or reverse proxy terminates the connection before your server sees it, and holds its own certificate. Renewing on the origin changes nothing a visitor can see.
The new certificate went to a different path. The server configuration still points at the old file. Compare the path in the configuration with where the renewal actually wrote.
Re-run the SSL Checker after each change. It reads the certificate the server is presenting right now, which is the only version that matters.
Why nobody noticed
A certificate does not expire without warning. It expires after warnings that went somewhere nobody was looking.
- Reminder emails went to a dead address — a former employee, an old agency, or the mailbox of whoever set the site up.
- Automatic renewal had been failing for weeks. Automated clients start trying about 30 days before expiry. Reaching zero means every attempt in that month failed and nothing reported it.
- The certificate was installed by hand, once, by someone who has since moved on, with no record that it would need doing again.
- Nothing was monitoring the date. Uptime monitoring that checks only whether the server answers will report a site with an expired certificate as healthy.
Stopping it happening again
Automate renewal, then verify the automation. A dry run exercises the whole process without issuing anything:
sudo certbot renew --dry-run
Monitor expiry separately from uptime. A check that alerts at 21 days leaves time to fix a broken renewal during working hours.
Send certificate email to a shared address, not an individual's.
Expect shorter lifetimes. Certificate lifetimes have been falling for years and the industry has agreed to keep shortening them. Renewing by hand once a year was already fragile, and it stops being practical as the interval shrinks. Automation is the only arrangement that survives that.
What an expired certificate does not mean
It does not mean the site was hacked, and it does not mean data was exposed while the certificate was valid. The encryption did not weaken on the expiry date. What ended is the browser's willingness to trust the certificate's identity claim, and it ends on a fixed date by design, so that a certificate cannot outlive the checks that were made when it was issued.
Once the new certificate is in place, confirm it with the SSL Checker: a valid expiry date, a complete chain, and the right hostname.