Is NET::ERR_CERT_DATE_INVALID a security risk?

It can be, which is why Chrome blocks the page. Usually it's a harmless expired certificate or a wrong local clock, but the same error also appears when something is tampering with the connection. Never enter credentials or payment details on a page showing this warning until the certificate is verified.

Why do I get this error on every website at once?

That pattern almost always means your device's clock is wrong, or antivirus/proxy software is intercepting HTTPS and re-signing it with mismatched dates. Fix the system time first; if that doesn't help, temporarily disable HTTPS scanning in your security software to confirm the cause.

I renewed the certificate but still see err_cert_date_invalid. Why?

Two common reasons: the web server wasn't reloaded so it's still serving the old certificate from memory, or the intermediate chain is missing or itself expired. Reload the service and re-check the live dates with openssl or an SSL checker rather than relying on the browser cache.

How to Fix NET::ERR_CERT_DATE_INVALID in Chrome

VigilDog Team · September 6, 2026 · 6 min read

You click a link, and instead of the page you get a red warning: NET::ERR_CERT_DATE_INVALID. It looks alarming, but it's one of the more mechanical TLS errors, and the cause is almost always a mismatch between a clock and a certificate's validity window. This guide explains exactly what triggers err_cert_date_invalid and how to clear it, whether you're a visitor who just wants the page to load or the person responsible for the server.

What NET::ERR_CERT_DATE_INVALID actually means

Every TLS certificate carries two timestamps: a "not before" date (when it becomes valid) and a "not after" date (when it expires). When Chrome negotiates a secure connection, it compares those two dates against the current time as your device sees it. If today's date falls outside that window, in either direction, Chrome refuses to trust the certificate and shows NET::ERR_CERT_DATE_INVALID.

The crucial detail hidden in that error is the word date. Chrome isn't saying the certificate is forged or the domain is wrong; it's saying the timing doesn't line up. That's why the same error can come from a genuinely expired certificate on the server or from a laptop whose clock is set three years into the future. Both produce identical-looking failures, and knowing which side is at fault is the whole job.

The five things that trigger err_cert_date_invalid

In practice, almost every instance of this error traces back to one of a short list of causes. Work through them in order of likelihood:

Your device's clock is wrong. A dead CMOS battery, a bad time zone, or a manually set date pushes "now" outside the certificate's window.
The certificate genuinely expired. The "not after" date has passed and nobody renewed it.
The certificate isn't valid yet. A freshly issued cert with a "not before" date in the future, or a clock that's running slow, hits this edge.
A middlebox is intercepting TLS. Some corporate proxies and antivirus "HTTPS scanning" features re-sign traffic with certificates whose dates don't match.
The wrong certificate is being served. On servers hosting several sites, a misconfigured virtual host can serve an old, expired cert for the wrong domain.

Fix it as a visitor: check your clock first

If you're just trying to reach a site, the fastest test is your own system time. Look at the clock in the corner of your screen. If the date or year is obviously off, correct it: on Windows go to Settings, Time & Language, and turn on "Set time automatically"; on macOS open System Settings, General, Date & Time, and enable automatic time. Then reload the page. A surprising share of these errors clear instantly once the clock is right.

If your clock is correct and the error persists on a single site, the problem is on the server side and there's little you can safely do from your end. Do not click through the warning on a login, banking, or payment page, an invalid certificate date can also indicate an interception attempt. If it happens on every HTTPS site at once, suspect antivirus HTTPS scanning or a corporate proxy, and try pausing that software to confirm.

Fix it as the site owner: renew and reinstall the chain

If it's your server throwing the error, the fix is almost always to renew the certificate and reinstall it correctly. With Let's Encrypt, run your ACME client (for example certbot renew) and reload the web server so it picks up the new files. With a commercial CA, issue the replacement, then install the new certificate alongside its intermediate chain, not just the leaf.

That chain matters more than people expect. A certificate is only trusted when the browser can build an unbroken path from the leaf you serve up to a root the browser already trusts. If you install the leaf but forget the intermediate, or install a stale intermediate that has itself expired, you can see date errors even after renewing the leaf. Serve the full chain your CA provides, in order, and restart the service.

The TLS certificate chain of trust

Verify the fix from the command line

Don't trust a browser cache to tell you it worked, check the live certificate directly. This one-liner prints the exact validity window the server is serving right now:

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

Confirm that notBefore is in the past and notAfter is comfortably in the future. If you'd rather not touch the terminal, our SSL checker reads the chain, dates, and issuer for any hostname in one click. Once it's green, do a hard reload (Ctrl+Shift+R) to clear Chrome's cached certificate state. For the broader question of what changes the day a certificate lapses, see what to do when an SSL certificate has expired.