ERR_CERT_AUTHORITY_INVALID

What it means

Chrome could not build a chain from the site's certificate up to a root certificate it trusts. That walk is the path validation of RFC 5280 § 6, and the trust anchor it starts from is an input to it (§ 6.1.1). Behind a debugging proxy the reason is almost always the same: the proxy signs certificates with its own certificate authority, and that CA's root certificate is not installed. Nearby errors are different problems: ERR_CERT_COMMON_NAME_INVALID is a name mismatch (RFC 9110 § 4.3.4, which defers to RFC 6125 § 6), ERR_CERT_DATE_INVALID is the clock or the validity dates (RFC 5280 § 4.1.2.5), and ERR_CERT_REVOKED means the certificate was revoked (§ 6.3).

How to fix it

Install the proxy's root certificate into the store that the browser actually reads. There is more than one store.

macOS. Double-click the .pem or .cer. It lands in Keychain Access, usually in the login keychain. Then the second step: open the certificate, expand Trust, set «When using this certificate» to Always Trust. Without it the certificate is stored but not trusted.

From a terminal, system-wide:

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain proxy-ca.pem

Windows. Run «Install Certificate» and change both defaults. The wizard opens on Current User and on «Automatically select the certificate store». Switch to Local Machine, then choose «Place all certificates in the following store» → Trusted Root Certification Authorities. Auto-select does not put it there.

The same thing in PowerShell, run as Administrator:

Import-Certificate -FilePath .\proxy-ca.cer `
  -CertStoreLocation Cert:\LocalMachine\Root

Linux. The paths differ per distribution. On Debian and Ubuntu the file must be PEM and must end in .crt, or update-ca-certificates skips it:

# Debian / Ubuntu
sudo cp proxy-ca.crt /usr/local/share/ca-certificates/proxy-ca.crt
sudo update-ca-certificates

# Fedora / RHEL
sudo cp proxy-ca.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Then restart the browser completely. Chrome caches the verification result, so an open tab keeps showing the error.

Why it may still not work

Firefox has its own store. Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import. The security.enterprise_roots.enabled flag in about:config makes Firefox read the system store as well, but only on Windows and macOS. On Linux that flag does nothing, so import the file.

Chrome ships its own list of root certificates. The Chrome Root Store is the default since Chrome 108 on Windows and macOS, 114 on Linux and ChromeOS, 115 on Android. It only replaces the list of public authorities: a certificate that you or an administrator added to the platform store is still trusted on a TLS connection. So the steps above work.

Node.js, Python, curl and Java do not look there at all. Each has its own list: NODE_EXTRA_CA_CERTS=/path/ca.pem, REQUESTS_CA_BUNDLE or SSL_CERT_FILE, curl --cacert ca.pem, keytool -importcert into cacerts. A browser that started working proves nothing about them.

There is no «Proceed anyway» button. Then the site uses HSTS: it is on the preload list, or it sent Strict-Transport-Security on an earlier visit. That button is missing by design, not by accident: RFC 6797 § 12.1 is titled «No User Recourse» and tells the browser not to offer it. Install the certificate.

See it on your own traffic

A debugging proxy shows its own root certificate and exports it in one click, which is where the install starts. After that you see the whole exchange: request, response, body. Until it is installed you only see a TLS handshake that starts and dies, the same signature as on a phone. Where the certificate ends up on each platform: Certificate Installation.