NET::ERR_CERT_AUTHORITY_INVALID (untrusted / self-signed CA)

What’s actually happening

Full red interstitial on every HTTPS hit to the site. Clicking "Advanced" shows "This server could not prove that it is example.com; its security certificate is not trusted by your computer's operating system." Hitting the same host with `curl` usually returns `SSL certificate problem: unable to get local issuer certificate`. Firefox often loads fine because it ships its own root store and may already trust an internal CA that Chrome doesn't.

Common causes

• The certificate is self-signed (a dev cert, a NAS/router/printer admin panel, a `mkcert` cert that was never added to the trust store).
• Issued by a private/internal CA whose root isn't installed on the visitor's machine.
• The server sends only the leaf cert and omits the intermediate, so the browser can't chain to a known root (the #1 cause on real public sites).
• A cross-signed or newly-rooted intermediate isn't trusted by older clients (e.g. devices that never got the new root in an OS update).
• Date/clock skew on the device making a valid root appear untrusted (less common — usually shows as ERR_CERT_DATE_INVALID instead).

How to fix it

1. Confirm whether the intermediate is actually being servedRun `openssl s_client -connect example.com:443 -servername example.com` and look at the "Certificate chain" block. If you see only the leaf (depth 0) and no issuer above it, the intermediate is missing. SSL Labs (ssllabs.com/ssltest) flags this as "Chain issues: Incomplete."
2. Fix an incomplete chain on the serverConcatenate the intermediate(s) after your leaf cert into the file your server points at. Nginx: the `ssl_certificate` file must be leaf + intermediate(s) in order. Apache: set `SSLCertificateChainFile` (or bundle into `SSLCertificateFile` on 2.4.8+). Reload and re-test. `certbot fullchain.pem` already includes the chain — point at that, not `cert.pem`.
3. For internal/private CAs, distribute the rootInstall the CA root into the trust store of every client: Windows via `certutil -addstore Root ca.crt` or Group Policy, macOS via Keychain (System keychain, set to "Always Trust"), Linux via `/usr/local/share/ca-certificates/` + `update-ca-certificates`. Browsers trusting the OS store will then chain correctly.
4. For local dev, stop using a bare self-signed certUse `mkcert` — it installs a local CA into the OS/browser trust store and issues localhost certs that chain cleanly, killing the warning without weakening your real browsing.
5. Last resort to view the page, not a fixType `thisisunsafe` while the warning page is focused, or click Advanced > Proceed. This bypasses the check for that session only and does nothing for your visitors — treat it as a debugging shortcut, never a solution.