NET::ERR_CERT_DATE_INVALID: What It Means and How to Fix It

NET::ERR_CERT_DATE_INVALID is Chrome’s code for “the certificate’s validity dates do not include right now.” It appears under the red “Your connection is not private” page, and Edge, Brave, Opera, and every other Chromium browser use the same code. Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE for the same condition.

The important thing to know is that this error has two very different causes, and they need two very different people to fix them:

• The certificate really is expired (or not yet valid). Every visitor sees the error. The site owner has to renew.
• The visitor’s device thinks the date is wrong. Only that visitor sees it. The site is fine.

Here is how to tell them apart in under a minute, then the fix for each.

Is it the site or is it you?

Open the error page and click Advanced. Chrome shows a sentence like “This server could not prove that it is example.com; its security certificate expired 3 days ago” or “…is not valid until…”. That sentence is Chrome’s reading of the certificate using your clock.

Next, check the certificate from a second source. Any of these work:

1. Load the site on your phone using mobile data, not Wi-Fi. If it loads, the problem is on the first device or network.
2. Run the site through the SSL certificate checker, which connects from an independent server and reports the certificate’s real dates.
3. From a terminal:

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

If the independent check says the certificate is valid, the cause is on the visitor’s side. If it says expired, the site owner has work to do.

Visitor-side causes and fixes

The device clock is wrong

By far the most common reason a single person sees this error on many sites. A dead CMOS battery, a VM restored from a snapshot, a phone that was off for months, a Raspberry Pi without a real-time clock, or a manually set time zone can all leave the clock days or years off. Certificates are validated against the local clock, so a clock set to 2019 makes every current certificate “not yet valid” and a clock set to 2030 makes them all “expired”.

Fix: enable automatic date and time. On Windows: Settings → Time & language → Date & time → Set time automatically. On macOS: System Settings → General → Date & Time → Set time and date automatically. On Android and iOS the option is under Date & time / General → Date & Time. Then reload the page.

Antivirus or a corporate proxy is intercepting HTTPS

Some antivirus suites and most corporate networks decrypt HTTPS traffic by presenting their own certificate to the browser. If that certificate has expired, or its signing authority was removed from the trust store, Chrome reports NET::ERR_CERT_DATE_INVALID for every site. The tell: click the padlock or the “Not secure” label, view the certificate, and look at the issuer. If it is your antivirus vendor or your employer rather than a public certificate authority, that is the culprit.

Fix: update the antivirus, or temporarily disable its “HTTPS scanning” / “web shield” feature to confirm. On a corporate network, IT needs to renew the interception certificate; there is nothing the website can do.

A captive portal is in the way

Hotel, airport, and café Wi-Fi networks redirect every request to a login page until you accept their terms. The redirect target presents the portal’s certificate under the name of the site you asked for, which Chrome rightly rejects. Fix: open a plain http:// site, or http://neverssl.com, log into the portal, then retry.

An old operating system without current root certificates

Windows 7, macOS before 10.12, Android before 7.1, and very old Linux images are missing newer root certificates. On those systems the chain cannot be built, and depending on which link fails, Chrome may report a date error rather than an unknown-authority error. Fix: update the OS, or at least its certificate store. For the technical version of this problem in scripts and servers, see curl (60) SSL certificate problem: certificate has expired.

Cached state in the browser

Rare, but after a certificate is renewed a browser tab that has been open for days can keep showing the error. Fix: close the tab, clear the site’s data (padlock → Site settings → Clear data), or restart the browser.

Site-side causes and fixes

The certificate has expired

The straightforward case. The renewal was missed, failed, or succeeded on disk without the web server reloading. The recovery steps for certbot, cPanel, Plesk, Cloudflare, IIS, and managed hosts are in Certificate has expired: how to fix it on any platform. The short version for a Linux box running certbot:

sudo certbot renew --force-renewal && sudo systemctl reload nginx

The certificate is not valid yet

Certificates carry a notBefore date as well. A certificate issued a moment ago by a certificate authority whose clock is a few seconds ahead of your server’s, or a certificate deliberately issued with a future start date, produces the same error until the start time passes. Let’s Encrypt backdates notBefore by an hour for exactly this reason, so this is usually seen with internal CAs or manually generated certificates.

Fix: wait, or reissue with a notBefore of now. Make sure the server’s clock is synchronised with NTP (timedatectl status on systemd systems).

An intermediate certificate expired

Your certificate’s own dates look fine, but the intermediate that signed it has expired, and the server is sending that old intermediate in the chain. Browsers that already trust a newer path may load the site; others fail. This happened at scale in September 2021 when Let’s Encrypt’s old root expired, and it happens again every time a certificate authority rotates an intermediate.

Detect:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout

then check each certificate’s dates. Fix: reinstall the certificate with the current intermediate bundle from your certificate authority. With certbot, fullchain.pem already contains the right intermediate; make sure the server config points at fullchain.pem, not cert.pem.

A CDN or load balancer is serving a stale certificate

The origin renewed correctly, but the layer in front of it did not. Cloudflare in Full (strict) mode, an AWS load balancer with a manually uploaded certificate, or a Kubernetes ingress with a Secret nobody updated are the usual suspects. The openssl check above tells you what the edge is serving; compare it with what the origin serves by connecting to the origin IP directly with -connect ORIGIN_IP:443 -servername example.com.

Stop it from happening again

For a visitor, the fix is a clock setting. For a site owner, the fix is renewal, but the real problem is that nobody knew the certificate was about to expire. Browser warnings are the worst possible monitoring system: they fire only after every visitor is already being turned away.

Check the served certificate on a schedule instead. SitesRadar’s free plan watches one site’s certificate and emails you 30, 14, and 7 days before it expires, alongside uptime, broken links, and DNS changes. If you manage several client sites, the SSL certificate expiration monitoring guide walks through thresholds and an inventory you can run across all of them.

FAQ

Can I bypass NET::ERR_CERT_DATE_INVALID? On a site without HSTS, Advanced → “Proceed to example.com (unsafe)”. On an HSTS site Chrome removes that link; typing thisisunsafe on the error page works in current Chrome but you should only ever do that on your own test server. Never tell customers to bypass it.

Why does only Chrome show the error? Usually it does not; the other browsers show it under a different name. If genuinely only Chrome fails, an extension or Chrome’s own certificate transparency requirements may be involved. Try an incognito window with extensions disabled.

The error appeared right after I renewed the certificate. Why? Either the server never reloaded, or the new certificate’s notBefore is slightly in the future relative to the client’s clock. Reload the server and wait a couple of minutes.

My site is on Cloudflare. Whose certificate expired? Click the padlock and check the issuer. “Cloudflare Inc” or “Google Trust Services” via Cloudflare means the edge certificate, which Cloudflare renews; check SSL/TLS → Edge Certificates for a stuck status. Anything else means your origin certificate, which you renew.