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

> Chrome shows NET::ERR_CERT_DATE_INVALID when a certificate is expired or not yet valid. Check the site first, then your clock, then renew.

Source: https://ssl.sh/errors/net-err-cert-date-invalid/
Last updated: 2026-11-10

**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](https://ssl.sh/tools/ssl-checker/) or run:

```bash
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:

```bash
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](https://ssl.sh/errors/wrong-system-clock-ssl-error/) 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:

```bash
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](https://ssl.sh/tools/chain-builder/) and replace the bundle file.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge / Brave | "Your connection is not private" (Edge: "isn't private") with `NET::ERR_CERT_DATE_INVALID` |
| Firefox | "Warning: Potential Security Risk Ahead" with [SEC_ERROR_EXPIRED_CERTIFICATE](https://ssl.sh/errors/sec-error-expired-certificate/), or `MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE` |
| Safari (macOS, iOS) | "This Connection Is Not Private"; the certificate details say it has expired |
| Chrome on Android | Same page and code as desktop Chrome; if the clock is wrong Chrome may say "Your clock is behind" or "Your clock is ahead" |

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](https://ssl.sh/tools/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:

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

With acme.sh:

```bash
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:

```nginx
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](https://ssl.sh/timeline/certificate-validity/)), manual renewal will fail eventually. Follow [automating renewal](https://ssl.sh/learn/automate-certificate-renewal/) and add an expiry alert so you hear about it before your visitors do.