Only one of my devices shows this error. Is the certificate broken?

Almost certainly not. If a single device or browser sees the error while everyone else loads the site fine, the certificate is valid and that device's clock is wrong. Fix the date, time, and timezone, and enable automatic time sync (NTP).

How is this different from NET::ERR_CERT_AUTHORITY_INVALID?

DATE_INVALID is about the validity window — the certificate is outside its notBefore/notAfter range, or the client clock makes it look that way. AUTHORITY_INVALID is about trust — the chain does not reach a trusted root. One is a time problem, the other is a trust problem.

Why did the error appear at an exact time, not gradually?

Certificate expiry is a precise timestamp (notAfter) in UTC, down to the second. The cert is trusted right up to that instant and rejected immediately after. There is no grace period.

Views: 12

NET::ERR_CERT_DATE_INVALID Fix

NET::ERR_CERT_DATE_INVALID means the cert is expired, not yet valid, or your clock is wrong. Tell the three apart in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome shows NET::ERR_CERT_DATE_INVALID and blocks the page with “Your connection is not private.” The certificate is presented, but it falls outside its valid date range — or the device thinks it does.

Symptoms

Chrome reports NET::ERR_CERT_DATE_INVALID; Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE (expired) or MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE (not yet valid).
The error started at a specific moment, often overnight, with no deploy.
Some devices reach the site fine while one machine or browser rejects it.

Top 3 Causes

The certificate expired - The notAfter date is in the past. This is the most common cause: an auto-renewal job broke, a manual renewal was missed, or the renewed certificate was issued but never deployed to the server. Affects every visitor at once.
The certificate is not yet valid - The notBefore date is in the future. Rarer, but it happens with a freshly issued cert deployed too early, or a server whose clock is set ahead of real time.
The client’s clock is wrong - The certificate is fine; the device’s date, time, or timezone is off. A clock skewed into the future makes valid certs look expired; a clock set in the past makes new certs look not-yet-valid. The tell: only that one device fails.

Diagnose with DechoNet

SSL Check to read the certificate’s actual notBefore and notAfter dates and confirm whether it is genuinely expired or still in range.
HTTP Check to confirm the final HTTPS response once a renewed certificate is deployed.

Resolution Checklist

First, rule out the client clock: does the site fail on every device, or just one? If just one, fix that device’s date/time and enable NTP — the certificate is fine.
Run openssl s_client -connect host:443 -servername host 2>/dev/null | openssl x509 -noout -dates to read the exact notBefore/notAfter.
If expired, renew the certificate and deploy the new file to the server — issuing a renewal is not the same as installing it.
If not-yet-valid, check the server’s own clock and confirm the issuance date; wait until notBefore or re-issue if the date was wrong.
Fix the renewal pipeline so it does not lapse again (e.g. confirm the certbot/ACME timer is running and not erroring).
Re-run SSL Check to confirm the served certificate is now inside its validity window.

When to Escalate

Escalate to your hosting or CDN provider if a managed certificate expired and you cannot trigger or deploy the renewal yourself.
If the certificate is clearly valid but a fleet of devices all report the error, suspect a network-wide time source (bad NTP server, broken DHCP option) rather than the certificate.