net::ERR_CERT_AUTHORITY_INVALID

The interstitial shows the code as "NET::ERR_CERT_AUTHORITY_INVALID"; automation tools (Playwright, Puppeteer, Selenium logs) report "net::ERR_CERT_AUTHORITY_INVALID", which is what our headless reproduction prints. Edge and other Chromium browsers use the same code.

Chrome, Edge and other Chromium browsers — certificate error interstitial "Your connection is not private"

What it means

Chrome could not chain the site's certificate to a root it trusts, so it blocks the page with the "Your connection is not private" interstitial. The certificate may be self-signed, issued by a private CA, presented without its intermediate, or substituted by something that intercepts the connection. Chrome uses the operating system's store on Windows and macOS (and its own Chrome Root Store for public CAs), and the NSS database on Linux.

Why it happens

• The server does not send its intermediate certificate

  common

  Chrome often fetches missing intermediates itself (AIA fetching) and may cache them, so the same misconfiguration fails only on some machines, apps or first visits.

• A self-signed or private-CA certificate

  common

  Routers, NAS devices, development servers and intranet sites with certificates the browser has never been told to trust.

• Something intercepts the connection

  common

  Antivirus HTTPS scanning, a corporate proxy whose root is missing on this device, captive portals on public Wi-Fi, or a real attacker.

• An outdated operating system or root store

  occasional

  Very old Android or Windows installations lack newer public roots, so modern certificates appear untrusted only there.

How to fix it

1. 1.

   Site owners: check the served chain

   If only one certificate is sent and its issuer is an intermediate, the server configuration is incomplete.

   # Site owners: which certificates does the server send? (1 = intermediate missing)
   openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'

2. 2.

   Site owners: serve the full chain

   Configure the web server with the full-chain file so every client (not just Chrome) can verify it.

   # nginx: serve leaf + intermediates
   ssl_certificate     /etc/letsencrypt/live/www.example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;

3. 3.

   Internal sites: install the private root on managed devices

   Distribute the company root through device management or the OS store; on Linux, add it to the NSS database Chrome reads.

   # Internal sites: install the company root on the client (Chrome uses the OS store on
   # Windows and macOS; on Linux, the NSS database in ~/.pki/nssdb)
   certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n corp-root -i corp-root-ca.pem

4. 4.

   Users: look at who issued the certificate before doing anything else

   The certificate viewer shows the issuer. Clicking through the warning ("Proceed to … (unsafe)") should be reserved for devices you own on networks you trust; on unknown networks it hands your session to whoever presented the certificate.

   Click "Not secure" in the address bar → "Certificate details" and read the issuer.
   A company or security-vendor name on a public site = TLS inspection on your network.
   An unknown issuer on public Wi-Fi = do not proceed.

← Browse the full signature error database