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

NET::ERR_CERT_DATE_INVALID means the current date is outside the certificate's validity period: either the certificate has expired, or your device's clock is wrong. Chrome shows it on the "Your connection is not private" page; Edge, Brave, Opera and other Chromium browsers use the same code.

Is it the site or your device?

Usually the site's certificate has expired; if an outside check shows it valid, your device clock is wrong. Test the site from a neutral place before you change anything. Open the SSL checker or run:

curl ssl.sh/example.com

• The checker says the certificate is expired: the site is at fault. Visitors can only wait or tell the owner; site owners should jump to "How site owners fix it".
• The checker says the certificate is valid: your device is the problem. Look at the date and time on the device that shows the error. A clock that reset to 2001 after a dead CMOS battery, a phone with automatic time turned off, or a virtual machine restored from an old snapshot all trigger this error on every HTTPS site.

A quick visitor-side hint: if every HTTPS site fails at once, it is almost always the clock or software on your device. If only one site fails, it is almost always that site.

Causes

1. The certificate expired (most common)

The renewal job failed, the new certificate was issued but never installed, or the web server was never reloaded. Confirm with:

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

If notAfter is in the past, renew and reload. Certbot and acme.sh write new files to disk, but Nginx and Apache keep serving the old certificate until they are reloaded.

2. The visitor's clock is wrong

Fix the clock, not the browser. On Windows, open Settings > Time & language > Date & time and turn on "Set time automatically", then click "Sync now". On macOS, enable "Set time and date automatically" in System Settings > General > Date & Time. On phones, enable automatic date and time. See wrong system clock for details.

3. The certificate is not yet valid

A certificate issued minutes ago can fail on a client whose clock runs slow. CAs usually backdate notBefore slightly to absorb small skew, so this mostly affects clients that are several hours or days behind.

4. An old certificate on one node or virtual host

Behind a load balancer or CDN, one server may still hold last year's certificate. Errors that come and go on refresh point to this. Test each origin IP separately:

curl -v --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null

5. An expired intermediate in the chain

If the server sends a stale intermediate certificate, some clients build the chain through it and fail. Rebuild the chain with the chain builder and replace the bundle file.

What it looks like in each browser

Chrome shows a dedicated clock interstitial ("Your clock is ahead/behind") when it is confident the device time is wrong. Treat that message as a strong hint to fix the time, not the website.

How site owners fix it

Renewing the certificate and installing it on every server and CDN that serves the site fixes it.

1. Check what is being served. Run the SSL checker or curl ssl.sh/example.com; it shows the expiry date, the full chain and every hostname in the certificate.

2. Renew. With certbot:

sudo certbot renew --cert-name example.com
sudo systemctl reload nginx

With acme.sh:

acme.sh --renew -d example.com --force
acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.crt \
  --reloadcmd "systemctl reload nginx"

3. Make sure the server points at the new file. In Nginx, ssl_certificate must reference the full chain file, not a copy you made last year:

ssl_certificate     /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;

4. Update every place the certificate lives. CDNs, load balancers, mail servers and hosting panels keep their own copies. Uploading to the origin does not update the CDN edge.

5. Automate and monitor. With certificate lifetimes falling to 200 days in 2026 and 47 days by 2029 (see certificate validity timeline), manual renewal will fail eventually. Follow automating renewal and add an expiry alert so you hear about it before your visitors do.