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

NET::ERR_CERT_DATE_INVALID is Chromium’s label when certificate validity dates fail—almost always renew the served leaf.

Chrome shows this code on interstitials and chrome://net-export logs. Operators grep it during incidents linking mobile and desktop reports.

Rare client clock skew can trigger date errors, but widespread reports mean server notAfter in the past.

First response

Chromium shows NET::ERR_CERT_DATE_INVALID when notBefore/notAfter is wrong. Fix clock skew on clients if needed, but almost always renew the expired server certificate.

Search interest in NET::ERR_CERT_DATE_INVALID rises when the leaf notAfter on the hostname customers type is already in the past. Clients cannot rewrite server certificate dates; they only accept chains that pass PKIX checks at handshake time.

For NET::ERR_CERT_DATE_INVALID: what it means and how to fix it, prove the failure from outside your office VPN before you change application code, purge caches, or ask end users to reboot. Capture the broken serial number and notAfter, renew on the listener that actually terminates that name, reload every node in the path, then re-run the same OpenSSL and browser checks that opened the incident.

Escalations for net-err-cert-date-invalid should cite fresh openssl notAfter compared with client clock only as secondary check output before anyone edits client code or blames Wi‑Fi. Chromium shows NET::ERR_CERT_DATE_INVALID when notBefore/notAfter is wrong. Fix clock skew on clients if needed, but almost always renew the expired server certificate. When NET::ERR_CERT_DATE_INVALID clusters around Chromium stacks on desktop and mobile, the expired material is usually bound to expired server leaf on the negotiated cipher suite instead of a mysterious platform bug. Executive summaries need the public hostname and current notAfter, not screenshots from a VPN-split test laptop.

See also Android SSL certificate expired errors and Certificate chain incomplete in the browser.

What this error means

Chromium checks notBefore ≤ now ≤ notAfter on each cert in the path. Expired intermediates trigger similar codes.

VM snapshots with wrong time cause false positives on internal tests only—confirm externally.

Deploy renewed fullchain to the public listener and verify code disappears in clean profile.

In PKIX terms, Chromium stacks on desktop and mobile treat the TLS Certificate message as authoritative: signatures must verify, each link must be within notBefore/notAfter, and only then does name matching run against CN and SAN. When the leaf expired, NET::ERR_CERT_DATE_INVALID is expected even if the issuer is publicly trusted. Guides titled net err cert date invalid still require reading dates on every certificate the server sends, including forgotten cross-sign intermediates.

Triage for net err cert date invalid should reject quick myths: flushing DNS or rebooting laptops does not move server notAfter forward. It is not proof the whole internet is broken when other HTTPS sites load for Chromium stacks on desktop and mobile. It is not interchangeable with registrar billing lapses unless revalidation fails later. It is not fixed by turning off TLS at the load balancer while marketing keeps publishing https:// links. Validated externally, openssl notAfter compared with client clock only as secondary check must show fresh dates on expired server leaf on the negotiated cipher suite before you close the incident.

Common causes

These patterns appear often during NET::ERR_CERT_DATE_INVALID incidents. They are not exhaustive, but they explain why renewal looked finished internally while strangers still received expired material.

Runbooks for net err cert date invalid most often break at handoff: certbot or a vendor portal issued new certs, but expired server leaf on the negotiated cipher suite never received a reload. Teams tracked PEM files in git while production continued serving the previous listener binding. OV renewals waited on legal approvers until NET::ERR_CERT_DATE_INVALID became customer-visible. Inventory spreadsheets omitted the hostname that Chromium stacks on desktop and mobile actually call during peak traffic.

Architecture amplifies net err cert date invalid: multiple regions, canary pools, or blue/green deploys can leave one ASG member presenting yesterday's fullchain. Shared IP default certificates silently terminate vanity hostnames without dedicated SNI rules. Mounted TLS secrets updated on disk while Envoy or nginx workers kept the old chain until signaled. Chromium shows NET::ERR_CERT_DATE_INVALID when notBefore/notAfter is wrong becomes harder to debug when only a fraction of Chromium stacks on desktop and mobile hit the stale anycast node.

Measurement gaps complete the story for net err cert date invalid. Synthetic monitors that disable certificate verification greenlit deploys that fail for real Chromium stacks on desktop and mobile. Redirect maps hid which hop expired until operators ran openssl notAfter compared with client clock only as secondary check per hostname. Dashboards celebrated TCP uptime while notAfter crossed midnight UTC without a page. Post-mortems should ask whether CT logs or stapled OCSP would have warned days earlier.

Confirm from the outside

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Paste notAfter into incident channel to align teams on root cause.

How to read the output

Start with openssl notAfter compared with client clock only as secondary check against the live customer hostname, capturing the leaf presented after SNI selection. Interpret notBefore= and notAfter= first: past notAfter guarantees failure for NET::ERR_CERT_DATE_INVALID regardless of pretty issuer branding. Next read subject= and any X509v3 Subject Alternative Name extension for alignment with the URL bar. Finally note issuer= so you know whether renewal changed intermediates; record serial numbers in the ticket for post-deploy diffing.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Parallel curl expiry errors reduce debate about Chrome-specific bugs.

Browser spot-check

Interstitial details link to net::ERR_CERT_DATE_INVALID text for screenshots.

Fix checklist

Work this list in order for net::err_cert_date_invalid: what it means and how to fix it. Each step should produce evidence (command output, timestamps, serial numbers) you can paste into the incident ticket.

1. Confirm repro off VPN.
2. OpenSSL served cert dates.
3. Renew and attach intermediates.
4. Reload all TLS terminators.
5. Purge CDN custom cert if stale.
6. Retest Chrome stable and Android.
7. Check intermediate expiry, not only leaf.
8. Add grep-friendly monitor on TLS metadata.

Roll out and verify

Procurement for net err cert date invalid begins with a reissue that lists every hostname Chromium stacks on desktop and mobile need, including forgotten admin and callback URLs. Validate CSR/key pairs, download CA bundles, and schedule work on expired server leaf on the negotiated cipher suite during a staffed change window. If automation handles ACME, prove challenges use the same DNS names customers resolve publicly, not internal-only labels.

Installation for net err cert date invalid means concatenating leaf and required intermediates the way your stack documents, then touching every node that terminates the name. Reload web servers, recycle ingress pods, or update cloud listener objects so data planes read new bytes. For load balancers, sync default and per-host certificates so SNI cannot fall back to expired defaults. Repeat openssl notAfter compared with client clock only as secondary check until fingerprints or serials change everywhere responders tested earlier.

Verification for net err cert date invalid must mimic strangers: external synthetics, mobile carriers, and CI jobs without corporate trust roots. Confirm NET::ERR_CERT_DATE_INVALID disappeared for Chromium stacks on desktop and mobile on flows heavier than GET /. Restore any strict TLS, HSTS, or CDN SSL modes relaxed during firefighting. Feed the hostname into continuous notAfter monitoring with thresholds well before the next CA-enforced renewal cliff.

What to automate

Certificate files on disk lie. Automate live TLS checks on the exact hostname and port users hit, including redirects and the certificate presented after TLS terminates on a load balancer or CDN. Pair certificate notAfter with RDAP domain registration expiry so re-validation is not blocked by a lapsed registrar.

Store historical notAfter in metrics to spot drift. Schedule alerts at 30, 14, 7, and 1 day before expiry so on-call has runway for ACME failures, manual OV revalidation, or change windows. Services such as ssldays can run external checks and renewal reminders without replacing your CA workflow.