ERR_CERT_AUTHORITY_INVALID website error explained

What it means

NET::ERR_CERT_AUTHORITY_INVALID is the Chrome error shown when the browser cannot trace the site's certificate back to a certificate authority (CA) it trusts. It produces the "Your connection is not private" warning page. The site's certificate may be valid and unexpired, but the browser cannot prove who issued it, so the connection is treated as untrusted. Unlike an expired certificate (which the date-invalid error covers), this is about trust in the issuer, not age.

Chrome validates the certificate against a root trust store: the operating system's root list on Windows and macOS, or the Chrome Root Store on Linux. The browser builds a chain from the leaf certificate on the server up through intermediate certificates to a root it recognises. If any link in that chain is missing or from an unknown authority, Chrome shows ERR_CERT_AUTHORITY_INVALID.

The common causes

Three situations produce this error most often.

1. A missing intermediate certificate on the server. This is the most common cause. The server sends the leaf certificate but not the intermediate certificate that connects it to a trusted root, so the browser cannot build the path. Some desktop browsers can fetch a missing intermediate automatically, which is why a site can work for you on one machine but fail for a visitor, a mobile browser, or an API client on another. Relying on that automatic fetch is unsafe, so the fix is to serve the chain, covered below.
2. A self-signed certificate. A certificate generated locally for testing is not signed by any public CA, so Chrome will never trust it by default. This is expected on a development machine but must never reach visitors. The certificate hierarchy article explains how a proper trust path is built.
3. A certificate from an untrusted or withdrawn CA. In rare cases the issuing CA has been removed from the trust stores (for example after a breach), so certificates it issued lose trust. An internal enterprise or proxy CA, such as one installed by traffic-inspecting security software, also produces this error until its root is distributed to client devices.

How the site owner fixes it

For most production sites the fix is to serve the complete certificate chain. When you obtain or renew a certificate, the CA provides the leaf and the intermediate certificates. Configure the server to present the leaf first, then the intermediates, in signing order, and verify that the configuration references the full chain file rather than the leaf alone.

For a Certbot or Let's Encrypt setup, that means pointing the server at fullchain.pem (leaf plus intermediates) instead of cert.pem (leaf only). The SSL renewal checklist and the certificate types reference walk the normal setup. If you have built the chain file by hand, concatenate the leaf first and the intermediates after it, each one signing the certificate before it, and never append the root (clients ignore it).

Verify the fix after deploying. Test from a device that has never visited the site and from a mobile browser, because chain problems are exactly where a warm cache hides the fault. The certificate error reference lists the other certificate warnings and their causes. If a visitor reports this error and the site owner confirms the chain is complete, the likely cause is on the visitor's side: a corporate proxy, security software, or an old device missing the internal root, so the fix is theirs, not the server's.