NET::ERR_CERT_INVALID causes

NET::ERR_CERT_INVALID is Chromium’s catch-all when PKIX checks fail—expiry, trust, name, or broken encoding. Prove what the server sends before blaming browsers.

Users paste the string into tickets alongside “site is down.” Marketing sees spike in bounce rate while curl from SRE laptops still works if someone disabled verification in a test script.

ERR_CERT_INVALID is broader than NET::ERR_CERT_DATE_INVALID. Treat screenshots as a starting point; openssl on the live hostname decides the class of failure.

First response

Ask for the exact interstitial code, URL bar hostname, browser version, and whether incognito reproduces. Collect openssl s_client with -servername matching the URL, note whether corporate SSL inspection is active, and whether the error is universal or limited to one region.

Document if the failure started immediately after a cert deployment or CDN upload—rollback decisions need serial numbers from openssl, not only screenshots.

NET::ERR_CERT_INVALID in executive summaries should cite public hostname, notAfter, and issuer from an external openssl capture. See ERR_CERT_AUTHORITY_INVALID when trust is the primary theme, and certificate chain incomplete when intermediates are missing.

What this error means

Chromium runs the server’s certificate chain through platform trust stores and PKIX rules. Failures map to user-visible codes; ERR_CERT_INVALID covers multiple underlying reasons, including expired or not-yet-valid windows, untrusted or missing issuers, malformed certificates, and some policy checks on certain builds.

Until you inspect the served chain, invalid is a symptom, not a diagnosis. Operators should classify the openssl failure mode, then pick renewal, chain repair, or trust store work.

Expired intermediates can trigger invalid interstitials while the leaf dates still look fine in a quick glance at PEM files on disk—use -showcerts during triage.

Common causes

Expired leaf or intermediate. The most frequent production cause; dates past notAfter trigger invalid interstitials even when the padlock worked yesterday.

Incomplete chain after renewal. New leaf mounts without intermediates, so browsers cannot build a path to a trusted root.

Wrong certificate on shared IP. Default vhost or CDN fallback serves a cert whose SANs omit the customer hostname.

Self-signed or private CA without enterprise trust. Lab certs pushed to production URLs.

MITM appliances with untrusted re-sign roots. Laptops off VPN succeed while office networks fail with invalid errors.

Broken PEM concatenation. Double headers or text corruption yields certificates Chromium rejects even when openssl parses them on some platforms.

CT or pinning edge cases. Rare on standard sites, but enterprise builds may surface invalid for policy reasons after CA migrations—still confirm dates first.

Confirm from the outside

OpenSSL

HOST=www.example.com
echo | openssl s_client -connect "${HOST}:443" -servername "${HOST}" -showcerts 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Chain depth

echo | openssl s_client -connect "${HOST}:443" -servername "${HOST}" 2>&1 | tail -30

curl parallel

curl -vI --connect-timeout 10 "https://${HOST}/" 2>&1 | grep -Ei 'SSL|certificate|expire'

How to read the output

Read notAfter first—if it is past, renew before chasing trust issues. If dates are valid, compare issuer names across the served chain depth with -showcerts. Match SANs to the URL hostname; CN alone is insufficient for modern Chromium checks.

Fix checklist

1. Classify: expired versus untrusted versus name mismatch using openssl and Chrome detail pane.
2. Renew or reissue if any link in the chain is out of its validity window.
3. Install the CA-provided full chain on the terminator that answers public DNS.
4. Reload web servers, ingress controllers, or CDN custom cert uploads.
5. Retest from external network without inspection proxies.
6. Confirm intermediates appear in the served chain, not only on disk.
7. Remove temporary browser flags or ignore-certificate-errors from demos.
8. Monitor live TLS on the public hostname with alerts before the next cliff.

Re-run the same curl and openssl commands that opened the ticket after every deploy step. Close only when strangers on multiple networks see a trusted padlock.

Post-mortems for NET::ERR_CERT_INVALID should ask which layer strangers hit—CDN, load balancer, or origin—and whether a canary pool served older PEM files. Capture serial numbers at open and close so future rotations can diff quickly. If the fix involved chain repair, archive the exact PEM concatenation order your terminator requires; the next renewal will repeat the same packaging rules.

Reject quick myths during NET::ERR_CERT_INVALID incidents: wiping browser data does not change server notAfter. Disabling HTTPS on the load balancer while marketing still advertises https links leaves customers exposed and does not count as resolved. When only one region fails, suspect stale POP or regional listener objects before rewriting application code.

When to use automation

ERR_CERT_INVALID tickets spike after silent expiry. Live TLS checks on the customer hostname catch notAfter drift before Chromium interstitials do. Try a quick read on /check, then schedule monitoring with thresholds at 30, 14, 7, and 1 days.

Add RDAP on the domain when OV revalidation depends on registrar contacts—registration lapses do not cause ERR_CERT_INVALID directly, but they block timely reissue.