SSL Certificate Expired: Fix It Fast
Your browser says SSL cert expired. Here's exactly what to check, in order of likelihood, with the real fix.
1. Your SSL Certificate Actually Expired (Most Common)
This is the boring one but it's the truth. Your SSL certificate has a lifespan — 90 days for Let's Encrypt, 1–2 years for paid certs. If you see ERR_CERT_DATE_INVALID in Chrome or SEC_ERROR_EXPIRED_CERTIFICATE in Firefox, the certificate's notAfter date is in the past.
How to verify
- Click the padlock icon in the address bar.
- Select "Certificate" (Chrome) or "Connection secure → More information → View certificate" (Firefox).
- Check the "Validity" dates. If today is after the "Not valid after" field, that's your culprit.
Fix: Renew the certificate
For Let's Encrypt certs: Run certbot renew on your server. This checks all certs and renews any expiring within 30 days. If you set up auto-renewal but it failed, check your cron job — a common failure is port 80 being blocked when certbot tries to validate domain ownership.
sudo certbot renew --dry-run # test first
sudo certbot renew # actual renewal
For paid certs (GoDaddy, Comodo, DigiCert): Log into your provider's dashboard, generate a new CSR (Certificate Signing Request) on your server, and paste it when renewing. Then install the new cert files — typically yourdomain.crt and yourdomain.key — onto your web server.
The reason step 3 works: The browser trusts the certificate only if the current time falls within its validity window. Once renewed, the new cert's notBefore date is now or earlier, and notAfter is far in the future.
2. Your System Clock Is Wrong (Second Most Common)
Here's the one that fools everyone. Your SSL certificate is perfectly fine, but your computer's clock says it's 2018. The browser compares the certificate's notAfter date against YOUR local time, not some global time server. If your clock is off by even a few hours and the cert expires soon, you'll trigger ERR_CERT_DATE_INVALID.
When this happens
After a CMOS battery dies on an old laptop, after dual-booting Windows and Linux without enabling hardware clock sync, or after a VM snapshot restore that didn't sync time. I've also seen it on Raspberry Pis that lost NTP connectivity.
Fix: Sync your clock
Windows 10/11:
- Right-click the clock → Adjust date/time.
- Toggle "Set time automatically" on. If it's already on, toggle it off, then on again.
- If that fails, run Command Prompt as admin:
w32tm /resync.
macOS:
- System Settings → General → Date & Time.
- Toggle "Set time and date automatically" on. If already on, pick a different server like
time.apple.com.
Linux:
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd
# or use chrony:
sudo chronyc makestep
The reason this works: SSL validation checks current_time < notAfter. Fixing the clock moves current_time back into the cert's valid window.
3. Your Antivirus or Proxy Is Intercepting SSL (Less Common but Sneaky)
Some security software — looking at you, Norton, McAfee, and corporate proxy tools like Zscaler — injects its own SSL certificate into your browser's trust store. That cert is often self-signed or expired, and it replaces the real site cert. You get ERR_CERT_DATE_INVALID or SEC_ERROR_UNKNOWN_ISSUER even though the site's cert is fine.
How to check
Click the padlock again. If the issuer is something like "Norton Security" or "Zscaler Root CA" instead of, say, "Let's Encrypt Authority X3", your antivirus is intercepting traffic. Also valid for corporate proxies that do SSL inspection.
Fix
For personal antivirus: Disable "SSL scanning" or "HTTPS scanning" in your AV settings. This is safe for most users — the AV uses this to scan encrypted traffic for malware, but modern browsers already do this. I've turned this off on every machine I've owned since 2018 and never had an issue.
For corporate proxies: You can't bypass this yourself. Contact IT and ask them to reissue the proxy's CA certificate. If you're the IT person, check the proxy's cert expiration date and renew it.
The reason step 3 works: Removing the intercepting cert lets your browser talk directly to the server, verifying the real, unexpired SSL certificate.
Quick-Reference Summary Table
| Cause | Check This | Fix |
|---|---|---|
| Certificate expired | Certificate validity dates | Renew cert with certbot renew or provider dashboard |
| System clock wrong | Your OS date/time | Sync clock via OS settings or w32tm /resync |
| Antivirus/proxy intercepting | Certificate issuer name | Disable SSL scanning or ask IT to renew proxy cert |
Start with #1. If you check the certificate and it's valid, jump to #2 — your clock. Only go to #3 if both are fine. In my experience, 80% of these errors are cause #1, 15% are #2, and 5% are #3.
Was this solution helpful?