ERR_CERT_AUTHORITY_INVALID

Browsers raise ERR_CERT_AUTHORITY_INVALID when the TLS certificate a site presents cannot be traced to a certificate authority that the browser trusts. The certificate may be perfectly valid structurally, but the chain of trust stops short of a root that is present in the browser's or operating system's trust store. The browser therefore refuses to treat the connection as secure and blocks the page before any content is exchanged.

What it means

Every HTTPS certificate sits at the bottom of a chain: a leaf certificate for the site, one or more intermediate certificates, and a root certificate. The browser trusts a fixed set of roots that ship with the operating system or the browser itself. To accept a certificate it must rebuild the chain from the leaf up to a trusted root, and every signature along the way must verify. If any link is missing or ends at a root the browser does not recognize, the chain is “invalid” and this error appears.

The common thread is trust, not encryption. The data on the wire may still be encrypted, but the browser cannot confirm that the certificate truly belongs to the domain and was issued by a body it accepts. Browsers deliberately treat this as a hard failure because a certificate the browser cannot verify is exactly what an attacker would present during interception.

The usual culprits are self-signed certificates, a private or internal certificate authority that has not been installed on the client, and a server that forgets to send its intermediate certificates. Rarer causes include a corporate proxy that rewrites TLS, an expired or misconfigured chain, or a captive portal on a public Wi-Fi network. Look at the certificate details before anything else.

Common causes

• A self-signed certificate, typical on development servers and internal appliances.
• Missing intermediate certificates, so the server sends only the leaf and the chain breaks.
• A private or internal certificate authority whose root is not installed in the client's trust store.
• A TLS-inspecting proxy, antivirus, or firewall that re-signs traffic with its own untrusted root.
• An expired certificate, a captive portal intercepting Wi-Fi logins, or a misconfigured site chain.

How to fix it

1. Inspect the certificate. Click the lock or warning panel and open the certificate viewer to see the issuer, the validity dates and whether a chain is shown. In Chrome you can also load chrome://certificate-manager to review installed authorities and their trust settings.
2. If it is self-signed or internal, trust the CA properly. Import the issuing root into the operating system's trust store rather than bypassing the warning. On Windows use certmgr.msc and place the root under Trusted Root Certification Authorities; on macOS add it in Keychain Access and set it to “Always Trust”.
3. If it is your own server, send the full chain. Configure the web server to include the intermediate certificates. With a typical nginx setup the chain file holds the leaf followed by the intermediates.

   ssl_certificate     /etc/ssl/certs/example.crt;
   ssl_certificate_key /etc/ssl/private/example.key;

4. Check for interception. Temporarily disable TLS-inspecting antivirus or proxy features and retry. If the error disappears, the proxy's root is the problem and must be trusted or the feature reconfigured.
5. Refresh trust data and time. Make sure the system clock is correct, update the browser, and on Windows confirm the root list is current. Then fully close and reopen the browser before retesting.

How to prevent it

For public sites, use certificates from a widely trusted authority and automate renewal so nothing lapses. Make “fullchain” the default when you configure TLS; shipping only the leaf certificate is one of the most common self-inflicted causes of this error. Verify your chain from outside your network, not just on the server itself, because a browser on another machine sees the chain exactly as it is delivered.

For internal services, run your own certificate authority deliberately: keep the root offline, issue intermediates for servers, and distribute the root to clients through managed policy so trust is established once and stays current. Never train yourself to click past the warning — a habit of ignoring trust errors defeats the protection entirely. If you must test with a self-signed certificate, do it on a separate hostname or profile and remove it afterwards.