Expired SSL Certificate: How to Fix NET::ERR_CERT_DATE_INVALID

Expired SSL Certificate: How to Fix NET::ERR_CERT_DATE_INVALID

An expired SSL certificate is one of the most common and painful causes of site downtime: the browser shows a red “Your connection is not private” screen (NET::ERR_CERT_DATE_INVALID) and visitors bounce. It usually happens after hours and stays undetected for hours. In this guide we walk through how to diagnose the issue, reissue the certificate, and set up monitoring so it never happens again.

How to confirm the certificate is really expired

Before you panic and reissue, make sure the problem is actually the expiry date — not a wrong system clock on the client or a stale cached chain. The fastest check is openssl:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
    | openssl x509 -noout -dates
# notBefore=Jan  1 00:00:00 2025 GMT
# notAfter=Apr  1 00:00:00 2025 GMT

If notAfter is in the past, the cert is really expired. Alternatively run enterno.io's free SSL Checker — it shows the expiry date, chain, and any issues in a single report. If the dates are still valid but the error persists, check the client's system clock and whether the origin is serving a stale cert from Nginx or CDN cache.

What browsers show: error codes and behavior

Different browsers surface an expired cert differently, but it's always a failed TLS handshake. Users either see a “Proceed (unsafe)” button or are completely blocked (e.g. with HSTS enabled). Common errors:

• Chrome/Edge: NET::ERR_CERT_DATE_INVALID
• Firefox: SEC_ERROR_EXPIRED_CERTIFICATE
• Safari: “Cannot establish a secure connection”
• curl: SSL certificate problem: certificate has expired

Key nuance: with HSTS preload, users cannot bypass the warning at all — that's by design to prevent MITM. See our HSTS and preload list guide.

Quick fix: reissue via Let's Encrypt

For most sites the best fix is a free Let's Encrypt cert with auto-renewal. If certbot is already installed, reissue takes 30 seconds:

# Stop nginx (for standalone mode)
sudo systemctl stop nginx

# Issue a new certificate
sudo certbot certonly --standalone -d example.com -d www.example.com

# Or without stopping, via webroot
sudo certbot certonly --webroot -w /var/www/html -d example.com

# Start nginx
sudo systemctl start nginx

After a successful issuance the cert lives in /etc/letsencrypt/live/example.com/. Make sure nginx points to the right files:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Full walkthrough in Free SSL via Let's Encrypt: certbot setup.

If the certificate is commercial and needs urgent renewal

For paid certs (DigiCert, Sectigo, GlobalSign), the workflow is different: log into the CA panel, find the expired cert, and start the renewal. You'll usually generate a new CSR and pass validation (DNS, email, or HTTP). Once issued, replace fullchain.pem and the key on the server, then reload:

sudo nginx -t && sudo systemctl reload nginx

If you need to restore the site immediately and CA validation is slow, temporarily deploy Let's Encrypt — it validates in minutes and you can switch back later.

Preventing it from happening again: expiry monitoring

The #1 cause of expiry is forgotten manual renewal. Three solutions:

1. Certbot auto-renew: 0 */12 * * * certbot renew --quiet renews 30 days before expiry.
2. External monitoring: services like Enterno.io Monitors check every 5 minutes and alert via Telegram/Email/Slack at 14, 7, and 3 days before expiry.
3. Server script: a bash job that parses openssl x509 and warns at < 14 days.

We recommend combining auto-renewal with external monitoring. Cron can silently fail (disk full, DNS down), and an external monitor catches it instantly.

Post-renewal sanity checks

After installing the new cert, verify:

• The chain is complete (fix incomplete chain).
• Cert covers both apex (example.com), www, and all needed subdomains.
• Modern cipher suites are used (see weak cipher suites).
• OCSP stapling is enabled — speeds up browser validation.

Frequently asked questions

Can I keep using a site with an expired certificate?

Technically yes — users can click “proceed unsafely”. Practically no: Google penalizes such sites in rankings, Chrome shows a full-page warning, and with HSTS the bypass isn't even possible.

My cert is expired but the new site loads fast — why?

The old cert is likely cached — in the browser, on CDN (Cloudflare, Fastly), or in an intermediate proxy. Purge the CDN cache and verify with openssl s_client from your server.

How long is a Let's Encrypt certificate valid?

90 days. Certbot auto-renews 30 days before expiry if cron is set. Since 2024, the CA/Browser Forum is moving toward 47-day max lifetimes — automation will become mandatory.

What if the certificate is revoked, not expired?

You'll see NET::ERR_CERT_REVOKED. Revocation usually means the key was compromised — generate a new key and CSR, never reuse the old key.

Conclusion

An expired SSL takes 10 minutes to fix with certbot, or a couple of hours for a commercial CA renewal. The real fix is preventing repetition: set up auto-renewal plus external monitoring. The enterno.io SSL Checker shows the expiry date, chain integrity, and config grade in 15 seconds — run it now, and Monitors will warn 14 days before the next renewal.

TLS 1.2 — RFC 5246, TLS 1.3 — RFC 8446. Online audit — SSL Labs and Mozilla Observatory. Let's Encrypt docs — letsencrypt.org/docs.