SSL Certificate Expired: How to Fix ERR_CERT_DATE_INVALID

Your connection is not private. ERR_CERT_DATE_INVALID. NET::ERR_CERT_DATE_INVALID. All three mean the same thing: the SSL certificate on your server has expired. Here's how to confirm it, fix it, and stop it happening again.

If you're seeing "Your connection is not private" or ERR_CERT_DATE_INVALID, your SSL certificate has expired. The browser checked the certificate's validity period, found today's date is past the expiry, and blocked the connection before the page loaded.

This is fixable. Here's how to confirm the diagnosis, find the expiry date, and renew the certificate — then set up monitoring so this doesn't happen on a weekend again.

Confirm It's Actually Expiry

ERR_CERT_DATE_INVALID specifically means date-related rejection — the certificate is structurally valid but outside its validity window. That said, confirm before fixing:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates

The notAfter line is the expiry. If that date is in the past, you have an expired certificate. If you don't have terminal access, the SSL checker runs the same check from a browser — enter the domain and you'll see the expiry date and current status immediately.

Fix It: Let's Encrypt / Certbot

If your certificate is issued by Let's Encrypt and auto-renewal should have handled this, force a renewal now:

certbot renew --force-renewal

Then reload the web server — this step is not optional:

systemctl reload nginx

Or for Apache:

systemctl reload apache2

After reloading, run the openssl check again or re-check in the SSL checker to confirm the new certificate is what's actually being served. If the expiry date still shows the old value, the server didn't pick up the new certificate — try a full restart instead of reload.

If certbot itself fails during the forced renewal, the Let's Encrypt auto-renewal failures post covers each failure mode: the ACME challenge being blocked, the systemd timer not running, wildcard certificate DNS credential expiry.

Fix It: Manually Managed Certificate

If you manage the certificate yourself through a CA dashboard (DigiCert, Sectigo, ZeroSSL, or similar):

✓Log into the CA dashboard and reissue or renew the certificate
✓Download the new certificate files
✓Replace the certificate and chain files on the server at the paths your web server config references
✓Reload the web server

The specific file paths depend on your setup — check your nginx or Apache SSL config for the ssl_certificate and ssl_certificate_key directives to confirm where the files live before replacing them.

Fix It: Behind Cloudflare

If your site runs behind Cloudflare and you're seeing a 526 error alongside the browser warning, Cloudflare is rejecting your origin certificate. The certificate at your origin server has expired — Cloudflare requires a valid certificate at origin when running in Full (Strict) mode.

Fix the origin certificate using the steps above, then confirm the origin is serving the renewed certificate before Cloudflare will resume proxying correctly. The Cloudflare SSL handshake failed post covers the 525 and 526 error modes in detail if the issue persists after renewal.

Why This Happened Despite Auto-Renewal

Auto-renewal is supposed to prevent exactly this. The most common reasons it fails silently:

✓The certbot systemd timer stopped running — typically after a server migration or rebuild
✓A firewall rule or reverse proxy config change blocked Let's Encrypt's HTTP-01 challenge after the initial setup
✓The certificate renewed on disk but the server was never reloaded, so the expired certificate kept being served
✓For wildcard certificates, DNS API credentials expired, blocking the DNS-01 challenge

Every one of these failure modes is invisible until the expiry date arrives. The certificate keeps working right up until it doesn't, and certbot logs its errors into a file nobody reads.

Stop It Happening Again

The certificate is fixed. The underlying problem — no external visibility into the expiry window — is what caused the outage, not the renewal mechanism itself.

External SSL monitoring checks the certificate being served from outside your infrastructure, the same way a browser does, on a daily schedule. If the renewal fails again, or if the server doesn't reload after renewal, the check catches the approaching expiry date and alerts you with enough lead time to act: 30 days, 14 days, 7 days, 1 day.

ExpiryPing runs this check daily for every domain you add — SSL via live TLS handshake, domain registration via WHOIS. No agent, no credentials, no server access. You add the hostname; it watches. Free for up to 3 domains, paid plans from $19/month.

Today's outage was caused by something that was visible for weeks before it happened. The certificate's expiry date doesn't move — it just needed something watching it.