NET::ERR_CERT_DATE_INVALID: what it means and how to fix it

NET::ERR_CERT_DATE_INVALID means a site's certificate is expired or your clock is wrong. How to tell which, and how to fix and prevent it.

1. The short answer

NET::ERR_CERT_DATE_INVALID means the site's HTTPS certificate isn't valid for today's date, as far as your device knows. Every certificate has a start and an end date. Either the certificate really has expired (or isn't valid yet), or your device's clock is wrong, which makes good certificates look out of date.

Telling them apart is easy: if lots of sites show it, fix your clock. If only one site does, on every device, its owner needs to renew the certificate. It's one of the Your connection is not private errors.

2. What you'll see

• Chrome: Your connection is not private, with NET::ERR_CERT_DATE_INVALID. If Chrome thinks your clock is the problem, it says Your clock is behind or Your clock is ahead instead.
• Edge: Your connection isn't private, with the same code.
• Firefox: Warning: Potential Security Risk Ahead, with SEC_ERROR_EXPIRED_CERTIFICATE, or SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE when a certificate in the chain has expired.
• Safari: This Connection Is Not Private, and the certificate details say it has expired.

3. What causes it

• The certificate expired. Renewal failed or was never set up. Common causes: a renewal job that stopped running, DNS that moved so validation fails, or a CAA record that blocks the authority.
• Renewed, but not loaded. The new certificate is on disk, but the web server still serves the old one until it's reloaded.
• One server of several is stale. A load balancer or a second server still has the old certificate.
• An expired intermediate or old chain. The server sends an outdated intermediate certificate alongside a new one.
• Your clock is wrong. A flat CMOS battery, a manually set clock or the wrong time zone. Phones and computers that sync time automatically rarely have this.
• A new certificate used too early, before its start date, which is rare.

4. Fixes for visitors, quickest first

1. Check your date, time and time zone. Turn on automatic time. On Windows, Settings, Time and language, Date and time, then Sync now. On a Mac, System Settings, General, Date and time.
2. Reload the page after fixing the clock, and restart the browser if it persists.
3. Try another device. If the site works there, it's your device.
4. If the site fails everywhere, its certificate has expired. Don't sign in or pay there until it's fixed; let the owner know.

5. Fixes for site owners

1. Confirm the dates your server is sending with openssl (below).
2. Renew the certificate. With certbot, run sudo certbot renew. On cPanel hosting, run AutoSSL and check the domain isn't excluded from it.
3. Reload the web server so it picks up the new file: sudo systemctl reload nginx, or the equivalent for Apache or Caddy.
4. Check every server and load balancer that serves the name.
5. Find out why renewal failed. Look at the ACME client's log. DNS that no longer points at the server, a firewall blocking port 80 for HTTP validation, or a CAA record are the usual reasons.
6. Automate and monitor. Renew well before expiry (Let's Encrypt suggests renewing 90-day certificates every 60 days) and use an external monitor, since Let's Encrypt no longer emails expiry warnings.

Certificate lifetimes are getting shorter. Under the CA/Browser Forum's ballot SC-081, the most a public TLS certificate can last fell to 200 days on 15 March 2026, and falls to 100 days in March 2027 and 47 days in March 2029. Manual renewal won't keep up, so automate it now.

On Cloudzyro Sites & Apps, certificates for your domains are issued and renewed for you, with nothing to buy or install. Renewal depends on your domain still pointing at us, so keep the CNAME for www to domains.cloudzyro.app (and the bare domain's A record to 173.234.137.167) in place, and if you have CAA records, keep letsencrypt.org, pki.goog and ssl.com allowed. We email you if a domain stops working.

6. A worked example

A site's visitors suddenly see NET::ERR_CERT_DATE_INVALID. The owner's certbot timer is running, so they're puzzled.

1. openssl s_client ... | openssl x509 -noout -dates shows notAfter was yesterday.
2. sudo certbot certificates lists a certificate valid for another 80 days. So renewal worked, but the server isn't using the new file.
3. The site runs on two servers behind a load balancer. Certbot only runs on one, and the other has a copied certificate from three months ago.
4. They renew on the second server too, reload nginx on both, and set up a check that alerts when any server's certificate has less than 14 days left.

When one visitor sees the error and another doesn't, a stale server behind a load balancer is a good first guess.

7. How to check

# The dates on the certificate the server sends right now
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -issuer

# Does it expire within 30 days? (2592000 seconds)
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 2592000

# curl shows "expire date" in its output
curl -vI https://www.example.com/ 2>&1 | grep -i "expire date"

# Your own clock
date                 # macOS and Linux
w32tm /query /status # Windows

notAfter is the expiry date, in UTC. If it's in the future and you still see the error, compare it with your own clock. If it's in the past, the server is serving an expired certificate: renew, then reload.

8. Sources

• Google Chrome Help: Fix connection errors
• Let's Encrypt: FAQ (certificate lifetime and renewal)
• Let's Encrypt: Ending support for expiration notification emails
• CA/Browser Forum: Ballot SC-081, reducing certificate validity periods
• RFC 5280: X.509 certificates (validity period)
• Mozilla Support: What does Your connection is not secure mean?