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

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](https://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](/guides/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:

- [FortiGate (SSL VPN and admin GUI)](/guides/fortigate-replace-ssl-certificate)
- [SonicWall (SSL VPN and management)](/guides/sonicwall-replace-ssl-certificate)
- [Sophos Firewall (VPN, portals and WAF)](/guides/sophos-firewall-replace-certificate)
- [IIS and Remote Desktop Services](/guides/iis-rds-replace-certificate)
- [Exchange hybrid](/guides/exchange-hybrid-certificate-renewal)

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](/guides/47-day-ssl-certificates).

## Check your domain

The [free scan](/#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](/tools/ssl-expiry-checker); to list every certificate for
your domain, use [find SSL certificates](/tools/find-ssl-certificates).

## Sources

- [Chromium source: net_error_list.h (CERT_DATE_INVALID)](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/net/base/net_error_list.h)
- [Chromium source: security interstitial strings (clock error page)](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/security_interstitials_strings.grdp)
- [OpenSSL: s_client manual](https://docs.openssl.org/3.0/man1/openssl-s_client/)
- [OpenSSL: x509 manual](https://docs.openssl.org/3.0/man1/openssl-x509/)
- [RFC 9162: Certificate Transparency 2.0](https://www.rfc-editor.org/rfc/rfc9162)
- [crt.sh: Certificate Transparency search](https://crt.sh)
- [CA/Browser Forum ballot SC-081: reducing certificate validity](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/)

---
Source: https://nameward.app/guides/net-err-cert-date-invalid (updated 2026-10-30)