NET::ERR_CERT_DATE_INVALID critical
NET::ERR_CERT_DATE_INVALID
The certificate is outside its valid window — expired or not yet active — or the device's clock is wrong, so today falls outside the cert's dates.
What you see
Your connection is not private NET::ERR_CERT_DATE_INVALID attackers might be trying to steal your information from example.com This server could not prove that it is example.com; its security certificate is not trusted because it is expired.
What’s actually happening
Browser throws a full-page warning and won't load the site. Every certificate carries a Not Before and a Not After date; the browser checks today against that window and rejects anything outside it. Could be the cert. Could be the clock. If it's the cert, it hits every visitor at once and traffic stops cold; if it's only your machine's date being wrong, you see it and nobody else does.
Common causes
- The certificate passed its Not After date — auto-renewal failed or was never configured
- A Let's Encrypt renewal timer (certbot.timer) silently stopped running
- The cert renewed but the web server was never reloaded, so it's still serving the old expired file
- The certificate isn't valid yet (Not Before is in the future) — usually a wrong server clock at issuance
- The client device's system clock is wrong (dead CMOS battery, bad timezone), making a perfectly valid cert look expired
How to fix it
- Check the dates and whether it's you or the serverecho | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates prints the real Not Before / Not After. If they look valid, check your own clock — a wrong device date triggers this with nothing wrong server-side. If the date has genuinely passed, it's the server.
- Renew the certificateLet's Encrypt: certbot renew (add --force-renewal if it claims it's not due). Paid cert: reissue through the provider and install the new files. Confirm the new Not After is roughly 90 days (LE) or a year out.
- Reload the web serverA renewed cert on disk isn't live until the server reloads it — a renew that didn't reload is a classic "renewed but still expired" trap. systemctl reload nginx (or apache2), then re-run the openssl date check to confirm the new dates are being served.
- Fix renewal so it can't recursystemctl status certbot.timer to confirm the auto-renew timer is active and ran recently. Most expired-cert outages are just a renewal job that quietly died weeks ago — re-enable it and add a deploy hook that reloads the server on renewal.
Stop it recurring
Run an external SSL/uptime monitor that alerts 14+ days before Not After, and pair auto-renewal with a post-renew reload hook so a renewed cert actually gets served.
Related errors