ERR_CERT_DATE_INVALID: expired certificate or wrong clock, and how to fix it

What ERR_CERT_DATE_INVALID means

Every TLS certificate carries two timestamps, "Valid from" and "Valid to" (the X.509 fields notBefore and notAfter). During the handshake, the browser compares those timestamps against its own idea of the current time. If the certificate's window has closed, or has not opened yet, or the browser's clock places "now" outside that window for any reason, the handshake stops before the browser even gets to checking who issued the certificate. Chrome and Edge show NET::ERR_CERT_DATE_INVALID. Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE for the expired case. Safari shows "This certificate has expired" or "This certificate is not yet valid."

Two separate situations produce the identical warning, and the browser cannot tell you which one it is: the certificate really is expired or not yet valid, or the certificate is fine and the client's clock is wrong. Both fail the same comparison.

How the error appears

In a browser, the page never loads and a full-tab warning appears instead of a padlock error icon on an otherwise-loaded page. Clicking "Advanced" shows the specific reason and, in Chrome, the certificate's own dates.

From the command line, curl reports the same failure with more precision:

curl -v https://example.com/
...
* SSL certificate problem: certificate has expired
* Closing connection

A not-yet-valid certificate produces a similar line reading "certificate is not yet valid." Server and application logs on the site owner's side usually show nothing at all for this error, because the TLS handshake fails before any HTTP request is logged. The evidence lives in the certificate and the client, not in the web server's access log.

What causes ERR_CERT_DATE_INVALID

• The certificate has expired. Renewal did not happen before the "Valid to" date, most often because an automated renewal job silently stopped running.
• The certificate is not yet valid. Less common: a certificate was issued or reissued with a "Valid from" date slightly in the future, or a server started serving a new certificate before its window opened.
• An intermediate certificate in the chain has expired. The leaf certificate can be perfectly current while an intermediate the server still sends has passed its own expiry, and some clients check every certificate in the chain.
• The visitor's device clock is wrong. A laptop that has been off for months, a phone with automatic time sync disabled, or a device with a dead CMOS battery can boot with a date years off in either direction.
• A virtual machine or container with a stale clock. VMs that were snapshotted, cloned, or resumed after a long pause frequently boot with a clock that has not caught up until an NTP sync completes.
• A misconfigured timezone or an incorrect manual date set by a user or a kiosk-style device that has no time source of its own.

How to tell whose fault it is

The fastest split is to check the certificate from somewhere other than the affected device. If a second device with a known-correct clock, or a checkpoint outside your own network, loads the site without a date warning, the certificate is fine and the problem is local to that one device's clock. If every vantage point reports the same expired or not-yet-valid date, the certificate itself needs attention. Running an SSL check from several locations at once settles this in one step instead of borrowing a second laptop to test with.

How to fix ERR_CERT_DATE_INVALID

If you are a visitor

1. Check your device's date, time and timezone first. This is the single most common self-inflicted cause, especially on Android devices with automatic time sync turned off, older laptops that sat unused, and machines with a failing CMOS battery. Turn on "Set time automatically" and confirm the year is correct, not just the clock face.
2. Try the site on a different device or network. If it loads cleanly elsewhere, your original device's clock (or a captive portal intercepting the connection) is the cause, not the site.
3. Read the actual dates on the warning page before doing anything else. Chrome's "Advanced" panel and the certificate viewer both show "Valid from" and "Valid to" in plain text, which tells you immediately whether the certificate is expired, not yet valid, or your clock is the outlier.
4. Do not click through on a certificate that is genuinely expired on a site handling anything sensitive. Once the clock is corrected, reload; do not just retry the same broken state.

If you run the site

1. Read the certificate's own dates directly instead of trusting a calendar reminder:

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

   This prints notBefore and notAfter straight from the certificate the server is actually presenting right now.
2. If you use Let's Encrypt, check the renewal job, not just the certificate. Let's Encrypt certificates last 90 days by design and renew automatically around the 30-day mark, but the automation can fail silently for weeks before anyone notices: systemctl status certbot.timer (or the equivalent cron entry) confirms the timer is still enabled and firing, and certbot renew --dry-run exercises the renewal path without changing anything live. Read /var/log/letsencrypt/letsencrypt.log for the actual failure, which is almost always one of: a DNS-01 challenge whose API credentials expired, a firewall change blocking the HTTP-01 challenge path, or Let's Encrypt's rate limits being hit during repeated troubleshooting.
3. Check the full chain your server sends, not just the leaf certificate:

   openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -

   Some servers keep serving an old intermediate certificate from disk after replacing the leaf. Every certificate in the chain needs a current validity window, since some clients validate the whole path.
4. Verify the server's own system clock. A server with the wrong time can issue automated renewals with an incorrect "Valid from" date, and can also fail its own OCSP and handshake validation independent of the certificate. Confirm NTP is running and synced.
5. Renew or reissue the certificate, then reload the web server. A renewed certificate sitting on disk does nothing until the process serving TLS picks it up: nginx -s reload, systemctl reload apache2, or the equivalent for a load balancer or CDN edge holding its own copy.
6. Confirm the fix from outside your own infrastructure after reloading, since a browser or OS on your machine may cache the old certificate for a session.

How to prevent ERR_CERT_DATE_INVALID

An expiring certificate gives no warning to anyone who is not specifically watching for it: the site keeps working right up until the exact second the window closes, then every visitor sees the same warning at once. A scheduled SSL check that reads the certificate's dates and alerts before the deadline, rather than after visitors start reporting a broken site, turns a silent renewal failure into a fixable ticket with days of lead time. HostTracker's SSL and domain expiry checks track the certificate's actual validity window from outside your infrastructure and alert by email, SMS, voice call, Slack, Telegram and more before it lapses; run one now with the SSL certificate check. The companion guide on checking SSL certificate expiry covers setting that up in more detail.

Related errors

• ERR_CERT_AUTHORITY_INVALID - the certificate's dates are fine, but the browser does not trust whoever issued it.
• ERR_CERT_COMMON_NAME_INVALID - the certificate is valid and trusted, but it was not issued for the hostname in the address bar.
• ERR_SSL_PROTOCOL_ERROR - the handshake failed before any certificate was even reached, usually a TLS version, port, or configuration mismatch.

Frequently asked questions

Is it safe to click through an ERR_CERT_DATE_INVALID warning?

Only if you are certain the cause is your own device's clock, since you can verify that independently. If the certificate itself is genuinely expired, clicking through removes the one check that confirms you are talking to the real server over an encrypted, verified channel.

Why does this happen right after I reset or unbox a device?

A factory reset or a long-unused device often boots with its internal clock reset to a default date, sometimes years in the past. Until it connects to the internet and syncs time automatically, every HTTPS site can fail with a date error, not just one.

Does clearing my browser cache fix ERR_CERT_DATE_INVALID?

Rarely. This error is a live comparison between the certificate's dates and the current clock, evaluated fresh on every connection, so a cache clear does not change the outcome. Correcting the clock or the certificate does.

Why did my Let's Encrypt certificate expire without any warning?

Because renewal is meant to be fully automatic, nobody checks it manually, so a broken cron job, an expired DNS API credential, or a changed firewall rule can silently stop renewals for weeks with no visible symptom until the certificate actually lapses.

Can a CDN or load balancer change what visitors see for this error?

Yes. If the CDN edge holds an expired certificate, every visitor sees the error regardless of what certificate the origin server has, so check whichever layer is actually terminating TLS for the request that failed.

How often should I check my certificate's expiry date?

A daily automated check is enough to catch a renewal failure with weeks of lead time, since Let's Encrypt certificates are valid for 90 days and most other certificates run 90 days to a year.