Why does this error show on every HTTPS site?

When NET::ERR_CERT_DATE_INVALID appears on every secure site you try, the cause is almost never the websites — it's your own device's clock. Browsers check each certificate's validity dates against your system time, so if your computer or phone thinks it's a different day, month, or year, every otherwise-valid certificate looks expired or not-yet-valid at once. Open your date and time settings and turn on automatic, network-provided time and time zone, then sync. On Windows use 'Set time automatically'; on macOS use 'Set time and date automatically'; on Android and iOS enable network-provided time. After the clock is correct, close and reopen your browser and revisit the site. If the error then clears across the board, the wrong clock was the culprit and nothing was ever wrong with the sites themselves.

How do I fix an expired certificate?

If you own the site and the certificate has genuinely passed its notAfter date, you need to renew it and make the web server serve the new one. With Let's Encrypt and Certbot, run 'sudo certbot renew' and then reload the web server with 'sudo systemctl reload nginx' (or apache2). With a commercial certificate authority, generate a CSR if required, complete domain validation, download the new certificate plus its intermediate chain, install both, and reload. The most common mistake is renewing the file on disk but never reloading the server, so the old expired certificate keeps being served. After reloading, verify from outside the server — using our SSL checker or openssl — that the live certificate now shows a future expiry date. Then set up automated renewal so this does not recur.

Why did it expire if I have auto-renewal?

Auto-renewal can fail silently in several ways even when you believe it's running. The renewal timer might be disabled or have stopped after a system update. The renewal might succeed but the web server is never reloaded, so it keeps serving the old certificate — fix this with a deploy hook like 'certbot renew --deploy-hook "systemctl reload nginx"'. The domain-validation challenge can also break if DNS records changed or a firewall rule started blocking the HTTP-01 path. Because any of these fail quietly, automation should always be paired with independent monitoring: an alert that checks the live certificate from outside the server and warns you when expiry is within about 14 days. Run 'sudo certbot renew --dry-run' periodically to confirm the whole renewal path still works end to end before a real renewal is due.

Can a wrong timezone cause it?

Yes, indirectly. Certificate validity is evaluated in absolute time, so the deciding factor is the actual instant your device thinks it is, not the label of the zone. A misconfigured timezone usually drags the underlying clock with it — for example, a device that resets to a default zone after a battery pull or a clock that drifted while offline can land hours or even days away from real time. If that shift pushes your device past a certificate's notAfter moment or before its notBefore moment, you'll see NET::ERR_CERT_DATE_INVALID. The reliable fix is the same as for any clock problem: enable automatic, network-provided time and time zone so the device resynchronizes with a trusted time source, then reopen the browser. Confirm both the time and the zone are right, since either being wrong can move you outside a valid window.

How to Fix NET::ERR_CERT_DATE_INVALID (Visitor & Owner)

If your browser refuses to open a site and shows NET::ERR_CERT_DATE_INVALID, it is telling you something very specific: the certificate the server presented is being judged against the current time, and the two do not agree.

The certificate is either past its expiry date, not yet valid, or your own device thinks the date is something it is not. Knowing which of those three it is decides whether this is a thirty-second fix on your laptop or a job for whoever runs the website.

What does this error actually mean?

Every TLS certificate carries two timestamps: a notBefore date and a notAfter date. Together they define the window in which the certificate is considered trustworthy. These two fields are required by RFC 5280 §4.1.2.5, the X.509 certificate standard.

When your browser connects over HTTPS, it reads those two dates and compares them against the clock on your device. If the current time falls outside that window in either direction, the browser stops the connection and shows NET::ERR_CERT_DATE_INVALID (Chrome and Edge wording; Firefox says SEC_ERROR_EXPIRED_CERTIFICATE or SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE, and Safari simply says the certificate is not valid).

There are only three ways to land outside that window:

The certificate has expired. The notAfter date is in the past. This is by far the most common cause when the error shows up on a single site that worked yesterday. Modern certificates from public authorities last roughly 90 days (Let's Encrypt) or up to about a year (398 days maximum), so they come up for renewal often.
The certificate is not yet valid. The notBefore date is in the future. You see this on a freshly issued certificate when the server's clock is running behind, or when a certificate was deployed before its activation date.
Your device's clock is wrong. The certificate is perfectly fine, but your computer or phone believes it is a different day or year, so a valid certificate looks expired or not-yet-valid to it.

The fastest way to tell the difference: if the error appears on every HTTPS site you try, the problem is almost certainly your device's clock. If it appears on only one site, that site's certificate has most likely expired.

If you're just visiting

Before you blame the website, check your own clock first. A wrong date or timezone on your device is the single most common visitor-side cause of this error, and it is the only one you can actually fix yourself. When the clock is off, a certificate that is genuinely valid for, say, June 2026 will look expired to a device that thinks it is 2023 — or not-yet-valid to one stuck in 2028.

Windows

Right-click the clock in the taskbar and choose Adjust date and time.
Turn on Set time automatically and Set time zone automatically.
Click Sync now, then confirm the date, time, and zone are all correct.

macOS

Open System Settings → General → Date & Time.
Enable Set time and date automatically and pick the correct time source.
Check that the time zone matches where you actually are.

Android

Open Settings → System → Date & time.
Turn on Use network-provided time and Use network-provided time zone.

iPhone / iPad

Open Settings → General → Date & Time.
Enable Set Automatically. If it is already on, toggle it off and on again to force a refresh.

After correcting the clock, fully close and reopen your browser, then revisit the site. If the date was the problem, the page loads normally.

If you have confirmed your clock is correct and the error still appears on that one site, the problem is no longer on your end — the site's certificate has expired, and only the site owner can renew it. Do not click through the warning to "proceed anyway" on sites where you log in or enter payment details; an expired certificate means you cannot be sure the connection is still protected the way it should be.

If you own the site

When visitors report NET::ERR_CERT_DATE_INVALID on your site and their clocks are fine, your certificate has lapsed. The fix is to renew and redeploy it, then make sure this never happens again.

Renew the certificate

If you use Let's Encrypt with Certbot, request a fresh certificate and reload the web server so it serves the new one:

# Renew all certificates that are due
sudo certbot renew

# Then reload the web server to pick up the new cert
sudo systemctl reload nginx   # or: apache2

With a commercial certificate authority, generate a new CSR if required, complete domain validation, download the issued certificate plus its intermediate chain, install both on the server, and reload. A renewed certificate that is on disk but not reloaded by the web server will not take effect — the old, expired one keeps being served until you reload or restart.

Automate renewal so it never lapses again

Manual renewal is how certificates expire. Certbot installs a timer that renews automatically, but the renewal only helps if your server actually starts serving the new certificate. Use a --deploy-hook so the web server reloads every time a certificate is renewed:

sudo certbot renew --deploy-hook "systemctl reload nginx"

# Confirm the renewal timer is active
systemctl list-timers | grep certbot

# Dry-run to prove renewal works end to end
sudo certbot renew --dry-run

Automation alone is not enough — monitor expiry independently so a silent failure (a broken hook, a DNS challenge that stopped working, a disabled timer) does not go unnoticed until visitors complain. Set an alert that fires when any certificate is within, say, 14 days of expiry, and verify the live certificate from outside your server rather than trusting that the renewal job ran.

Check the not-before date on freshly issued certificates

When you have just issued a certificate and immediately see a date error, do not assume expiry — check the notBefore date and your server's clock. You can inspect both dates straight from the command line:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates
# notBefore=Jun 26 00:00:00 2026 GMT
# notAfter =Sep 24 23:59:59 2026 GMT

Want to check your certificate's expiry date?

Check your SSL configuration →

The SSL checker reports the validity window and the daysToExpiry value, so you can see at a glance whether the certificate the public actually receives is current — and how long you have before the next renewal is due.

Why does a brand-new certificate show this error?

It is entirely possible to get NET::ERR_CERT_DATE_INVALID on a certificate that was issued five minutes ago. If the issuing authority stamps a notBefore date that is slightly in the future — or, far more often, if your server's clock is running fast and is ahead of real time — the certificate is technically "not yet valid" from the browser's point of view, even though it will never expire for another three months. The cure is to make sure the server's time is synced with NTP before and after issuance, and to wait until the activation moment has genuinely passed. A brand-new certificate throwing a date error is almost always a clock-skew story, not an expiry one.

Where to go next

For the wider family of certificate and connection warnings — name mismatches, untrusted issuers, and mixed content — see the pillar guide, the complete guide to SSL/TLS errors. If you have confirmed the certificate is genuinely expired and want a focused walkthrough of renewing and redeploying it cleanly, read how to fix an expired SSL certificate.

How to Fix NET::ERR_CERT_DATE_INVALID