Skip to content

Guides · Certificates

NET::ERR_CERT_DATE_INVALID on your own site: how to fix it

Visitors see NET::ERR_CERT_DATE_INVALID on your site. How to tell an expired or uninstalled certificate from a visitor's wrong clock, and fix it.

Updated 30 October 2026 · 4 min read

Chrome shows NET::ERR_CERT_DATE_INVALID under "Your connection is not private" when the certificate a server presents is, by the browser's clock, either expired or not yet valid. Chrome's own source code lists the possible reasons: the server is presenting the wrong certificate, the visitor's clock is wrong, or (rarely) someone is presenting an old certificate whose private key they obtained.

If you run the site, the first question is whether the problem is on your side or the visitor's.

Step 1: one visitor or everyone?

  • Everyone, or everyone on one network or region: it's your server. Go to step 2.
  • One person, one device: check that device's date and time first. Chrome has a separate warning for this case, with the heading "Your clock is behind" or "Your clock is ahead" and a button to update the date and time. Setting the clock to update automatically fixes it.

If the device clock is right and only some visitors see the error, it's probably still your server: one of several hosts behind the name is serving an old certificate.

Step 2: see what the server actually serves

Run this from any machine with OpenSSL:

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

notBefore and notAfter are the validity dates. If notAfter is in the past, the certificate has expired. -servername matters: without it, a server that hosts several sites may return a different, default certificate.

Step 3: check every host behind the name

A name can point at several addresses: a pool of web servers, a load balancer with several nodes, IPv4 and IPv6. Check each one:

for ip in $(dig +short A www.example.com) $(dig +short AAAA www.example.com); do
  echo "== $ip"
  openssl s_client -connect "[$ip]:443" -servername www.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -serial -enddate
done

If one address returns an older serial and expiry date than the others, that host is the one causing the errors. Visitors whose connection lands on it see the warning; everyone else doesn't. That's why these reports often seem random.

Step 4: compare with the newest certificate issued

Every publicly trusted certificate is logged in Certificate Transparency. Search crt.sh for your hostname. If a newer certificate exists than the one being served, the renewal happened but the install didn't. Certificate renewed but not installed covers that case in detail.

Fix it, by cause

The certificate expired and was never renewed

  1. Renew it with your CA or ACME client.
  2. Install it on every host and service that uses the name, with the intermediate certificate.
  3. Reload or restart the service, then rerun the check from step 3.

It was renewed, but the server still serves the old one

This is common on firewalls, VPN gateways and Windows servers, where the new certificate has to be imported and selected by hand. Use the runbook for your system:

On Linux web servers, the new file is often on disk but the running process still holds the old one. nginx, Apache and HAProxy need a reload.

One node or load balancer still has the old certificate

Install the new certificate on the host that step 3 found. If a load balancer or CDN terminates TLS, the certificate has to be updated there, not only on the servers behind it.

The certificate isn't valid yet

If notBefore is in the future for the visitor but not for you, their clock is behind. A correct device clock fixes it.

Why this keeps happening

Public TLS certificates are limited to 200 days from 15 March 2026, 100 days from March 2027 and 47 days from March 2029 (CA/Browser Forum ballot SC-081). More renewals mean more chances for one host to be missed. Automating the install, not only the renewal, is the lasting fix. See 47-day SSL certificates.

Check your domain

The free scan finds every certificate issued for your domain in the CT logs, connects to each host, and flags expired certificates and hosts still serving an old one. To check a single host, use the SSL expiry checker; to list every certificate for your domain, use find SSL certificates.

Sources

Free scan

No signup. Only scan domains you own or manage.

More in Certificates