NET::ERR_CERT_AUTHORITY_INVALID
`NET::ERR_CERT_AUTHORITY_INVALID` means Chrome could not build a path from the certificate the server presented to any root in its trust store. There are three causes, in rough order of frequency: the certificate is self-signed, so nothing vouches for it; the server is not sending its intermediate certificates; or a TLS-inspecting proxy is re-signing traffic with a CA the machine does not trust. Run `openssl s_client -connect host:443 -servername host -showcerts` and count the certificates returned to tell which.
What Chrome is telling you #
Chrome walked from the certificate the server sent toward a root, and ran out of links before reaching one it trusts. That is a trust failure, not a hostname failure and not an expiry failure — so the fix has to add a link or add trust, not reissue the certificate.
Find out which cause you have #
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
| grep -E "^ *[0-9]+ s:" Expected output
0 s:CN = example.com 1 s:C = US, O = Example CA, CN = Example Intermediate CA
| What you see | Cause |
|---|---|
| One certificate, subject = issuer | Self-signed |
| One certificate, issuer is a public CA | Missing intermediate |
| Two or more, ending in an unfamiliar root | TLS-inspecting proxy or private CA |
Cause A — the certificate is self-signed #
openssl x509 -in certificate.crt -noout -subject -issuer Expected output
subject=CN = localhost issuer=CN = localhost
Identical subject and issuer means nothing independent vouches for it, so no browser will accept it without being told to. For local development, install it in the trust store — and make sure it has subject alternative names, or it will still be rejected afterwards. See generating a self-signed certificate.
For anything with real users, use a real CA. A free TLS certificate is automatable and costs nothing, which removes the last reason to self-sign a public service.
Cause B — the server is not sending its intermediates #
This is the one that looks like a browser bug and is not. A single certificate from a publicly trusted CA means the chain is incomplete, and the fix is on the server:
cat certificate.crt intermediate.crt > fullchain.crt Full detail at unable to get local issuer certificate.
Cause C — a private or corporate root #
If the top of the chain names your employer or a security vendor, traffic is being intercepted and re-signed by a corporate proxy — normal on managed networks, and the root is normally pushed to managed devices automatically. Containers and fresh machines miss it.
Install the root your IT department provides:
sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain corporate-root.crt Import-Certificate -FilePath corporate-root.crt `
-CertStoreLocation Cert:\LocalMachine\Root sudo cp corporate-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates Chrome caches verification results, so restart it fully after installing.
What not to do #
Clicking Advanced → Proceed accepts an unverified identity. It is a reasonable way to confirm a diagnosis and a bad habit to build, because it trains you to dismiss the one warning that distinguishes a misconfiguration from an interception.
Frequently asked questions
- How is this different from ERR_CERT_COMMON_NAME_INVALID?
- This one is about trust — the chain does not reach a trusted root. The other is about identity — the chain is fine but the certificate does not cover the hostname you asked for. Different causes, different fixes.
- It works in Firefox but not Chrome. Why?
- Firefox ships its own trust store and ignores the operating system's on most platforms, so a root installed for the OS is not visible to it, and vice versa. A root you install must go in the store the browser actually uses.
- Is clicking "Advanced → Proceed" safe?
- It is safe to diagnose with and wrong to rely on. Proceeding accepts an unverified identity for that session, so the connection is encrypted but you have no assurance about who is on the other end.
- I installed the root and it still fails. Why?
- Chrome caches certificate verification aggressively. Restart the browser fully. On macOS, also check the certificate is marked "Always Trust" for SSL in Keychain Access rather than merely present.
References
- Mozilla CA certificate policy — the rules behind what reaches a browser trust store
- RFC 5280: X.509 and CRL profile — the specification every field on a certificate comes from