Browser ERR_CERT_AUTHORITY_INVALID on HTTPS

Fix Chrome ERR_CERT_AUTHORITY_INVALID for self-signed certificates and internal CAs by trusting the CA locally or using a proper development certificate.

intermediatedebuggingbrowsertlshttps

Symptoms

Your connection is not private — NET::ERR_CERT_AUTHORITY_INVALID
A local HTTPS dev server shows the warning while curl -k works
The site works after bypassing but API calls from the page fail

Possible causes

A self-signed certificate is used for HTTPS development
The issuing CA is not installed in the OS/browser trust store
A corporate proxy re-signs traffic with a proxy CA
The certificate chain is incomplete (missing intermediate)

Diagnosis steps

Open the certificate viewer and read the issuer

Interpretation

A self-signed leaf or an internal CA name tells you what must be trusted.

Inspect the chain for missing intermediates

openssl s_client -connect localhost:443 -showcerts </dev/null

Interpretation

If the server omits the intermediate, browsers cannot build a path to a trusted root.

Confirm curl without -k fails the same way

curl -v https://localhost:443

Interpretation

A verification failure outside the browser proves it is a trust issue, not a browser extension.

Root cause

ERR_CERT_AUTHORITY_INVALID means the browser could not build a chain from the server certificate to a root in its trust store. For local development this is usually a self-signed certificate; for internal services it is a CA that was never installed; for intercepted traffic it is a proxy CA. The page may still load after a bypass, but fetch calls remain blocked because the connection is untrusted.

Fix

Install your development CA into the OS trust store (and the browser if it uses its own), or generate a certificate with a tool like mkcert that adds a locally trusted root. Serve the full chain including intermediates. Never disable TLS verification in production code; fix trust at the CA level instead.

Verify the fix

Reload the HTTPS page; the padlock appears with no authority warning, and in-page fetch calls to the same origin succeed without bypassing the interstitial.

Symptoms

Chrome reports NET::ERR_CERT_AUTHORITY_INVALID for a local or internal HTTPS site. Bypassing the warning lets the page load, yet scripts that call the same origin may still be treated as untrusted.

Diagnosis

Read the issuer and chain:

openssl s_client -connect localhost:443 -showcerts </dev/null

If the issuer is “self signed” or an internal CA, the browser has no matching root.

Fix

Trust a local CA and serve the full chain:

mkcert -install
mkcert localhost 127.0.0.1 ::1

Point the dev server at the generated certificate and key. Install corporate CA certificates system-wide in corporate environments.

Verification

Reload the page; the address bar shows a valid padlock with no warning, and same-origin fetch calls complete without the certificate interstitial.

Development vs Production Certificates

Local development is exactly where self-signed certificates are appropriate, but they must never leak into production. Tools like mkcert generate a root that is trusted only on your machine, so the warning disappears locally without weakening real traffic. In CI, never disable verification to make tests pass; instead inject a test CA into the container trust store. When an internal service uses a private CA, distribute that CA through configuration management so every client trusts exactly one additional root rather than disabling checks broadly, which would remove protection against real interception.