net::ERR_CERT_AUTHORITY_INVALID means Chrome couldn't verify the certificate presented by a site against a trusted certificate authority — distinct from an expired certificate or a hostname mismatch, this specifically means the chain of trust back to a known, trusted root CA is broken or missing entirely.
This error means the certificate's issuing authority isn't recognized as trusted by the browser (or the OS's trust store it relies on) — commonly a self-signed certificate used without being explicitly trusted, an internal/corporate CA not installed in the client's trust store, or (more rarely) an actual man-in-the-middle situation the browser is correctly protecting against.
Why This Error Happens
Browsers verify a presented certificate by checking its chain of signatures back to a root certificate authority present in the operating system's (or browser's own) trusted root store. This error fires when that chain can't be completed with a trusted root — a self-signed certificate has no such chain at all, an internal CA's root certificate might not be installed on the specific client machine, and a genuinely compromised network could present an untrusted certificate as part of an actual attack, which is exactly the scenario this check exists to catch.
Reproducing the Error
A local development server using a self-signed certificate:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes
node server.js # HTTPS server using this self-signed cert
Visiting https://localhost:3000 in Chrome:
Your connection is not private
NET::ERR_CERT_AUTHORITY_INVALID
An internal service using a corporate/internal CA not installed on the current machine:
Visiting https://internal-service.company.local:
NET::ERR_CERT_AUTHORITY_INVALID
(the internal CA's root certificate isn't in this machine's trust store)
Core Concepts Behind This Error
For local development, a self-signed certificate genuinely has no path to a trusted root, since it's signed by itself rather than an actual CA — this is expected and the standard fixes are either explicitly trusting that specific certificate locally, or using a tool like mkcert that generates locally-trusted development certificates by installing a local CA into your system's trust store.
For internal/corporate services, the fix is installing the organization's internal CA root certificate into the client machine's trust store, a one-time setup step typically handled by IT/device management tooling — this is different from trusting an individual site's certificate, since it establishes trust for any certificate issued by that internal CA going forward.
For a public, production website, this error should never appear for legitimate visitors and typically indicates either a genuine misconfiguration (an incomplete certificate chain missing an intermediate certificate) or, in rare and concerning cases, an actual network-level attack — this distinction matters significantly for how urgently and how you should respond.
"Proceed anyway" (Chrome's advanced option to bypass this warning) should never be used for a genuinely untrusted or unexpected certificate on a public site, since doing so defeats the exact protection this check provides — it's appropriate only for known, deliberately self-signed local development certificates you set up yourself.
Fixing "net::ERR_CERT_AUTHORITY_INVALID"
Fix 1: For local development, use mkcert to generate a locally-trusted certificate instead of a plain self-signed one:
brew install mkcert
mkcert -install # installs a local CA into your system trust store
mkcert localhost # generates a cert trusted by browsers on this machine
Fix 2: For internal/corporate services, install the organization's internal CA root certificate into your system trust store (process varies by OS and organization, often via device management):
# macOS example — adding a CA cert to the system keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain internal-ca.crt
Fix 3: For production sites, verify the certificate chain includes all necessary intermediate certificates, not just the leaf certificate — an incomplete chain is a common misconfiguration cause:
openssl s_client -connect yourdomain.com:443 -showcerts
# verify the full chain, including intermediates, is present and correctly ordered
Fix 4: If this appears unexpectedly on a site you don't control and have visited successfully before, treat it as a potential security concern rather than something to bypass — investigate via a different network before assuming it's safe to proceed.
Is It Ever Safe to Click "Proceed Anyway" on This Warning?
Only for certificates you deliberately created and understand — a local development self-signed certificate you generated yourself, or a known internal CA certificate for a service you trust and recognize. For any public site, or any certificate you didn't personally set up and don't fully understand the origin of, treat this warning as a genuine signal not to proceed, since it may indicate an actual network compromise, and the whole point of certificate authority validation is that you shouldn't need to manually judge trust on a per-connection basis.
Preventing This Error in Production
Use mkcert or an equivalent tool for local development HTTPS rather than plain self-signed certificates, so your browser trusts the certificate without warnings during normal development work. For production, verify your certificate chain includes all necessary intermediate certificates as part of your deployment/renewal process, and monitor certificate expiration and chain validity proactively rather than discovering issues through user-facing browser warnings.
If you hit this error, determine first whether it's your own local development certificate (expected, fixable with mkcert), an internal CA needing installation, or an unexpected warning on a site you don't control (treat cautiously, don't bypass) — the appropriate response differs significantly across these three cases.