NET::ERR_CERT_DATE_INVALID is Chrome's way of saying the website's certificate is not valid right now: either the certificate has expired (or is not yet valid), or the clock on your own device is wrong, so a perfectly good certificate looks expired. Google's own data shows the second cause is far more common than most people expect: on Windows, a wrong system clock is behind 33.5% of all Chrome certificate warnings, versus 4.23% for certificates that have really expired (Acer et al., ACM CCS 2017). This guide shows you how to tell the two apart in under a minute, how to fix each one as a visitor or a site owner, and how to stop the error coming back.
What NET::ERR_CERT_DATE_INVALID actually means
Every TLS certificate carries two timestamps: a start date (notBefore) and an end date (notAfter). When Chrome, Edge or any Chromium-based browser opens an HTTPS connection, it compares those two dates with the current time as reported by your device. If "now" falls outside that window, the browser refuses to trust the certificate and shows a full-page warning with the code NET::ERR_CERT_DATE_INVALID.
There are only three ways to land outside the window, and they point at different people:
| Situation | Whose problem | What Chrome shows |
|---|---|---|
| Your device clock is wrong (usually years behind) | The visitor | "Your clock is behind" or "Your clock is ahead", with no option to proceed |
| The site's certificate has expired | The site owner | "Your connection is not private", NET::ERR_CERT_DATE_INVALID |
| The certificate was issued minutes ago and your clock is slightly behind | Both | "Your connection is not private", NET::ERR_CERT_DATE_INVALID |
Other browsers report the same underlying condition under different names. Firefox uses SEC_ERROR_EXPIRED_CERTIFICATE for an expired certificate and MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE for one whose start date is still in the future. Safari shows "This Connection Is Not Private" and mentions the expiry only in the details. The fixes below apply to all of them.
Visitor or website owner? Find out in 30 seconds
Before changing anything, work out which side of the connection is wrong:
- Open two or three other HTTPS sites. If they all show the same warning, the problem is your device, almost certainly its clock. If only one site fails, the problem is on that server.
- Look at the date in your taskbar or menu bar. A device that has just replaced its battery or sat unused for months often boots with a date years in the past. If the year is wrong, you have found the cause.
- Check the site from another device or network. If your phone on mobile data opens the site without a warning, your computer is the odd one out.
- If you own the site, check the certificate from outside. A free FortifyNet scan reads the live certificate from the internet and shows its exact notBefore and notAfter dates, independent of any device clock.
Why this error is more often your clock than the website
Google and Carnegie Mellon researchers studied more than 300 million Chrome certificate warning reports to find out what really triggers them. The result, published as "Where the Wild Warnings Are" at ACM CCS 2017, is striking: on Windows, an incorrect system clock caused 33.5% of all certificate warnings, eight times more than certificates that had really expired. On macOS the split was 8.71% versus 4.39%, and on Android 8.46% versus 2.73%.
Share of Chrome certificate warning reports caused by a wrong device clock versus a genuinely expired or not yet valid server certificate, by operating system. Source: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017, Table 1.
Two more details from the same study matter for the fix. Nearly all wrong clocks were in the past, not the future: the client clock was more than 24 hours behind in 6.7% of reports and more than 24 hours ahead in only 0.05%. And when a certificate had genuinely expired, it was usually a recent lapse: 57% of expired certificates had expired less than 30 days earlier, which is the signature of a renewal that somebody forgot, not a site that was abandoned.
The Chrome team used this data to build the "Your clock is behind" screen you may have seen. It first relied on a simple heuristic that compared the system time with the browser's build date, which caught only 68% of clock errors. In May 2017 Chrome shipped a secure time service that asks a Google server for the real time when it sees a date error, raising detection to 96%. When Chrome shows the clock-specific screen, 53% of users fixed their clock before dismissing it, compared with 3.9% when they only saw the generic warning. That screen deliberately has no "proceed anyway" link, so the only way past it is to correct the clock.
Fix ERR_CERT_DATE_INVALID as a visitor
Windows 10 and 11
Open Settings, go to Time & language, then Date & time. Turn on "Set time automatically" and "Set time zone automatically", then click "Sync now" under Additional settings. If the clock drifts again after every restart, the CMOS battery on the motherboard is probably flat; the researchers named dying CMOS batteries as one likely reason so many Windows clocks are wrong. From an administrator command prompt you can also force a resync with w32tm /resync.
macOS
Open System Settings, then General, then Date & Time, and turn on "Set time and date automatically". Make sure the time zone is also set automatically. If the option is greyed out, disconnect from any VPN first and try again.
Android and iPhone
On Android, open Settings, then System, then Date & time, and enable "Set time automatically" (some manufacturers call it "Use network-provided time"). On iPhone and iPad, go to Settings, General, Date & Time, and enable "Set Automatically". A device that has been powered off for a long time or had its SIM removed can boot with a stale date.
If the clock is right and the error persists
- Old devices and expired roots. Certificates are trusted through a chain that ends at a root certificate on your device, and roots expire too. When the cross-signed Let's Encrypt chain expired on 30 September 2024, devices running Android 7.0 and earlier stopped trusting sites that use Let's Encrypt certificates, while Android 7.1 and newer, which already trusted ISRG Root X1 directly, were unaffected (Let's Encrypt). On a device that cannot be updated, Firefox is often the workaround, because it ships its own root store instead of using the operating system's.
- Antivirus HTTPS scanning. Security products that inspect HTTPS traffic install their own root certificate and re-sign every site you visit. The CCS 2017 study traced a wave of date errors on properly configured sites to antivirus software whose own root certificate had expired. Temporarily disabling HTTPS or "web shield" scanning tells you whether that is the cause; updating the product usually fixes it.
- Update the browser and clear the SSL state. An outdated browser may lack newer root certificates. On Windows, Internet Options, Content, "Clear SSL state" clears cached certificates that Chrome and Edge share with the system.
Fix ERR_CERT_DATE_INVALID as a site owner
If visitors are reporting the error and the site fails from more than one device, the certificate itself is the problem. Work through these steps:
Step 1: read the real dates. Query the certificate the server is actually serving with OpenSSL:
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
The output prints notBefore and notAfter. If notAfter is in the past, the certificate has expired. If notBefore is in the future, it is not yet valid.
Step 2: renew and reload. With an ACME client such as Certbot, sudo certbot renew obtains a new certificate, but the web server keeps serving the old one from memory until you reload it (sudo systemctl reload nginx or the Apache equivalent). Our renewal guide covers every major platform and CDN.
Step 3: check the whole chain. Your leaf certificate can be valid while an intermediate in the chain has expired. Deploy the full chain the CA gave you (fullchain.pem, not cert.pem), and check every endpoint that terminates TLS: the origin server, the load balancer and the CDN edge can each hold a different copy.
Step 4: beware the "not yet valid" trap. A certificate that becomes valid at the exact minute it is issued will fail for every visitor whose clock is even slightly behind. The CCS study recorded a spike in clock-related warnings on Windows in September 2016 when Google rolled out newly issued certificates at short notice. Most public CAs now backdate the start time slightly for this reason, but if you run a private CA, set notBefore at least an hour in the past.
Step 5: verify from outside. There is no propagation delay for certificates. As soon as the server is reloaded, an external scan shows the new dates.
| Cause | How to recognise it | Who fixes it | Fix |
|---|---|---|---|
| Certificate expired | notAfter in the past; error on every device | Site owner | Renew, install full chain, reload server |
| Certificate not yet valid | notBefore in the future; error for some visitors right after deployment | Site owner | Wait, or issue with a backdated start time |
| Intermediate or root expired | Leaf looks fine, chain check fails | Site owner (or CA) | Install the updated chain |
| Device clock wrong | Every HTTPS site fails; Chrome says "Your clock is behind" | Visitor | Enable automatic time, replace CMOS battery |
| Old device missing new roots | Only newer sites or certain CAs fail | Visitor | Update OS, or use a browser with its own root store |
| Antivirus root expired | Error on well-configured sites, disappears when HTTPS scanning is off | Visitor | Update or reconfigure the security product |
Why date errors will get more frequent, not less
Certificate lifetimes are shrinking. Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of a public TLS certificate dropped from 398 to 200 days on 15 March 2026, falls to 100 days in March 2027 and to 47 days in March 2029 (CA/Browser Forum). Let's Encrypt is moving its default from 90 to 45 days (Let's Encrypt). Every renewal is a chance to miss the deadline, so a site that renews by hand will meet NET::ERR_CERT_DATE_INVALID several times a year. Automating issuance with ACME, configuring the reload hook, and monitoring expiry from outside are no longer optional.
Related guides
- "Your connection is not private": what it means and how to fix it covers the warning page this error appears on.
- SSL certificate expired: what happens and how to fix it fast goes deeper on the server-side cause.
- How to renew an SSL certificate walks through renewal on every major platform.
- ERR_CERT_AUTHORITY_INVALID: causes and fixes handles the chain errors that often follow a rushed renewal.
FAQ
Is NET::ERR_CERT_DATE_INVALID dangerous?
Usually not, but Chrome cannot tell a harmless clock error from an attack, so it blocks the page. Fix the clock or wait for the site to renew instead of clicking through, especially on banking or login pages.
Why does Chrome say "Your clock is behind" on one site but "connection is not private" on another?
Chrome only shows the clock-specific screen when its secure time check confirms your clock is wrong. If the check cannot complete within three seconds, or the difference is small, you get the generic warning with the same error code.
Can I bypass the error?
On the generic warning you can click Advanced and proceed, unless the site uses HSTS, which removes that option. On the "Your clock is behind" screen there is no bypass by design; correcting the clock is the only way through.
My clock is correct and only one site fails. What now?
The site's certificate has expired or its chain is broken. Nothing on your device will fix that; tell the site owner, or check the site's certificate dates yourself with an external scan.
How do I stop this happening on my own site?
Automate renewal with ACME, configure the deploy hook that reloads the server, and monitor expiry from outside with alerts at 30, 14 and 7 days.
Check your certificate dates before your visitors do
A wrong clock is the visitor's problem; an expired certificate is yours. Run a free FortifyNet scan to see your certificate's exact validity dates, the full chain, protocol configuration, security headers, DNS and email authentication in about 60 seconds. No signup required.
Sources: Acer et al., "Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors", ACM CCS 2017; Let's Encrypt, Shortening the Chain of Trust; CA/Browser Forum, Ballot SC-081v3; Let's Encrypt, From 90 to 45.
Originally published at fortifynet.com/blog/err-cert-date-invalid. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.
Top comments (0)