You're browsing, and suddenly Chrome slams a full-page warning: Your connection is not private, with error code NET::ERR_CERT_DATE_INVALID. You didn't change anything. The site worked yesterday. What's actually happening here is your computer is telling the website's security certificate that today is a different day than it really is.
That error code specifically means the certificate's validity period doesn't cover the current date your system believes. Certificates have a "not before" and "not after" range. If your PC's clock is set to 2019, every 2024 certificate looks like it's from the future. If your clock is set to 2026, everything looks expired.
I've seen this happen on Windows 10 machines more than any other OS, usually after a CMOS battery dies or when someone travels across time zones without letting Windows update automatically. Here's how I fix it, starting with the most common cause.
Cause 1: Your System Date and Time Are Wrong
This is the cause in about nine out of ten cases. When the certificate's validity window doesn't include your current date, Chrome refuses to connect. It's not being paranoid—it's doing exactly what it should. An expired certificate could mean a compromised server.
First, right-click the clock in your taskbar and pick Adjust date/time. Or just hit Win + I, then go to Time & Language.
Turn on both Set time automatically and Set time zone automatically. If they're already on, toggle them off, wait a few seconds, then turn them back on. That forces Windows to re-sync.
If that doesn't work, click Sync now under the Synchronize your clock section. You'll see the last sync time and status. If it fails, you might have a firewall or corporate policy blocking NTP (port 123).
# Alternatively, force a sync from an admin Command Prompt:
w32tm /resync
The reason step 3 works is that w32tm talks directly to time.windows.com. If it returns "The command completed successfully", your clock is now correct. Reload the page. If the warning's gone, we're done.
One more thing: check your time zone. I've fixed laptops that were set to UTC+2 when the user was actually in UTC-5. The hours were right, but the offset was wrong. That produces the same error because the certificate's validity is based on UTC, not your local time.
Cause 2: The Website's Certificate Truly Is Expired
Sometimes it's not you—it's the site. Small blogs, old forums, and some government sites run on expired certificates. You can't fix their server from here, but you can verify it's actually their problem before you blame your machine.
Here's the tell: the error message will say Certificate is expired or Certificate is not yet valid. If your clock is fine and the site still fails, open the error details. Chrome gives you a Not secure icon in the address bar—click it, then click Certificate. You'll see the validity period. If today's date is outside that range, it's on them.
For a quick check, open a different browser like Firefox. Firefox uses its own certificate store, and it'll give you a similar warning but with the option to View Certificate directly. Or use an online checker like SSL Labs—but make sure the domain is public.
If the site's cert is expired, you have two choices: wait for the admin to renew it (often takes a day or two) or use an archived version. Don't bypass the warning unless you're absolutely sure the site is legit and you're not entering any passwords. I've seen phishing sites deliberately use expired certs to see who's desperate enough to click through.
Cause 3: Antivirus or VPN Interfering with HTTPS
This one's sneaky because your clock is perfect and the cert is valid, yet Chrome still throws the error. What's actually happening is your antivirus is doing a man-in-the-middle on your HTTPS traffic. Tools like Kaspersky, Avast, and Bitdefender inject their own root certificate to scan encrypted traffic. If that certificate expired or wasn't properly installed, Chrome sees an untrusted chain.
Same goes for some VPNs with a "web protection" feature. They route your traffic through their proxy, which uses its own cert. If that cert's clock range doesn't match, you get the error.
To test this, temporarily disable the HTTPS scanning feature in your AV. In Kaspersky it's under Settings > Network settings > Scan encrypted connections. In Avast, it's Protection > Core Shields > Web Shield > Configure > Enable HTTPS scanning. Turn it off, restart Chrome, and try the site again. If it loads, that was the culprit.
If you don't want to disable scanning entirely (fair enough), update the AV to the latest version. The root cert they install gets refreshed with updates. A stale AV after a Windows update is a classic trigger.
Also check for any rogue proxy settings. In Chrome, go to chrome://settings/security and scroll to Advanced. Click Open proxy settings and make sure Automatically detect settings is on and there's no weird proxy listed under LAN settings.
Quick-Reference Summary Table
| Cause | Symptom | Fix |
|---|---|---|
| Wrong system clock | Error appears on many sites, not just one | Enable auto time/timezone, sync now, or run w32tm /resync |
| Server cert actually expired | Only one site fails, clock is correct | Check cert validity in browser; wait for renewal or use another site |
| AV/VPN HTTPS interception | Random sites fail, including ones with valid certs | Disable HTTPS scanning temporarily, update AV, check proxy settings |
If you've tried all three and still get NET::ERR_CERT_DATE_INVALID, you might have a corrupt SSL cache. Clear it by going to chrome://net-internals/#sockets and clicking Flush socket pools. Then in chrome://settings/clearBrowserData, check Cached images and files and clear it. Usually that's the last resort—and it often works because old cached certificates get stuck.