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.

Updated August 19, 2026 Verified against OpenSSL 3.5.7

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 #

Count what the server sends
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