NET::ERR_CERT_AUTHORITY_INVALID: What It Means and How to Fix It

err_cert_authority_invalid means your browser cannot build a valid chain from the website’s certificate to a root certificate authority it trusts. The message net::err_cert_authority_invalid identifies a trust failure, not proof that the website is malicious.

Start by checking whether one website fails or many unrelated websites fail. Then follow the relevant path below: visitors should isolate the device or network, owners should inspect the deployed certificate chain, and developers should configure explicit trust for their local or internal CA.

What does err_cert_authority_invalid mean?

The browser received a certificate but could not establish trust in its issuing authority. Encryption alone cannot establish that the server is the intended destination.

A typical chain runs from the website’s leaf certificate through intermediate certificates to a trusted root. The server supplies the leaf and necessary intermediates; the client needs an acceptable trust anchor. An untrusted self-signed leaf, an unavailable intermediate or an unfamiliar private CA can break that process.

Chromium distinguishes authority, date and hostname failures in its network error definitions. Diagnose the exact code before changing settings.

What causes err_cert_authority_invalid?

Check the trust anchor, the chain the server sends and possible certificate substitution. Use this 3-step trust check to separate those causes.

• Is the root trusted? A private CA or self-signed development certificate may be unknown to this client.
• Does the server supply the necessary intermediates? A valid leaf alone may be insufficient. DigiCert’s chain documentation explains the intermediate’s role.
• Is something re-signing traffic? An authorized inspection service or local security tool may present a replacement certificate whose CA is missing from the client’s trust configuration.

Interception is a change to the connection, not another link in the certificate chain. These neighboring errors need different fixes, following Chromium’s definitions:

How do you fix it as a visitor?

Compare the connection before changing trust settings. If one site fails across independent devices and networks, report it to the owner.

• Check the clock anyway. Correct the date, time and time zone, but clock problems usually belong to DATE_INVALID.
• Try another trusted network. Compare home broadband with mobile data. On public Wi-Fi, complete the network’s legitimate sign-in flow.
• Try a private window. If the result changes, investigate extensions and browser configuration.
• Update the browser and operating system. Restart and retry after supported updates.
• Investigate HTTPS scanning. On a personally managed device, temporarily test with that feature disabled, then turn it back on. Seek a supported repair if it caused the failure.

These isolation steps align with Google’s certificate-error guidance. On managed equipment, ask IT before changing security software.

Do not proceed into banking, login or payment pages with unresolved certificate warnings. For the broader warning, see our connection-is-not-private guide.

Why does it happen on ALL websites?

Failures across unrelated websites point toward a shared device, trust-store or network problem. They are less consistent with every website independently deploying a broken certificate.

• One site, several devices: investigate the site’s chain or a shared network path.
• Many sites, one device: investigate local trust, security software and managed settings.
• One browser or app: compare its certificate configuration with a working client.
• Several devices, one network: investigate the gateway, captive portal or inspection service.
• Works on another network: compare routing, DNS and the certificates presented on each path.

Synchronize the clock, inspect the issuer and record which comparisons changed the result. An unexpected organization appearing as issuer across unrelated domains is a useful clue, not sufficient proof of legitimate inspection. Send IT the affected URLs, exact errors and issuer details.

Leave DNS flushing and browser reset until last. A DNS flush can only help a stale resolution problem; it cannot install a missing trust anchor. A reset does not repair the remote server’s certificate chain. If the connection fails before certificate exchange, use the separate proxy-not-responding troubleshooting guide.

How do site owners repair the certificate chain?

Serve the correct leaf certificate and required intermediates from every TLS endpoint. Replace an untrusted self-signed production certificate with one appropriate for your visitors.

Check the actual hostname, load balancer and origin separately. DigiCert recommends installing missing intermediates for incomplete-chain errors.

Replace example.com below with your hostname. OpenSSL documents these verification options:

openssl s_client -connect example.com:443 \
  -servername example.com -verify_hostname example.com \
  -verify_return_error -showcerts </dev/null

-showcerts displays what the server sent; it does not establish a verified chain. -verify_return_error makes verification failures abort, while the hostname options select and check the intended host. Results depend on the local trust configuration. See the OpenSSL s_client documentation.

For an existing Let’s Encrypt deployment managed with Certbot, test renewal using the documented dry run:

certbot renew --dry-run

A successful Certbot renewal test does not prove production is serving the renewed files. Verify the deployed chain after renewal and reload, and monitor the certificate expiry visible to clients.

Cloudflare exception: Origin CA certificates are not browser-trusted. Disabling proxying, pausing Cloudflare or accessing the origin directly can expose this error. Restore the intended proxy configuration or install a publicly trusted origin certificate for direct access. Cloudflare’s Origin CA troubleshooting documents this distinction and compatibility with Full (strict) mode.

How do you create a trusted localhost certificate?

Create a development CA, trust it on the development machine, and configure the server with a certificate covering the names you actually use. Trusting the CA alone does not configure HTTPS.

The mkcert README documents these installation options. Run only the option matching your system:

# macOS with Homebrew
brew install mkcert

# Windows with Chocolatey
choco install mkcert

# Debian/Ubuntu prerequisite
sudo apt install libnss3-tools
# Then install the appropriate Linux binary from mkcert's official releases.

After installation, generate explicitly named files:

mkcert -install
mkcert -cert-file localhost.pem -key-file localhost-key.pem \
  localhost 127.0.0.1 ::1 app.test

For app.test, add 127.0.0.1 app.test to your operating system’s hosts file. The URL hostname must match a certificate subject alternative name (SAN). Never share rootCA-key.pem; keep generated private keys out of source control.

For an existing Next.js project, the Next.js CLI accepts a custom development certificate and key:

npx next dev --experimental-https \
  --experimental-https-key ./localhost-key.pem \
  --experimental-https-cert ./localhost.pem

For an existing Vite project, merge this into vite.config.js. Vite’s server.https configuration accepts HTTPS server options:

import { defineConfig } from 'vite';
import { readFileSync } from 'node:fs';

export default defineConfig({
  server: {
    https: {
      key: readFileSync('./localhost-key.pem'),
      cert: readFileSync('./localhost.pem'),
    },
  },
});

Clients may need explicit CA configuration. The following documented options preserve verification: Node’s NODE_EXTRA_CA_CERTS, Requests’ verify parameter and curl’s –cacert option.

# Run in a POSIX shell; replace app.js with your Node entry point.
NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem" node app.js
curl --cacert "$(mkcert -CAROOT)/rootCA.pem" https://localhost:3000/

import subprocess
from pathlib import Path
import requests

ca_dir = subprocess.check_output(['mkcert', '-CAROOT'], text=True).strip()
response = requests.get(
    'https://localhost:3000/',
    verify=str(Path(ca_dir) / 'rootCA.pem'),
    timeout=10,
)
print(response.status_code)

Use the port your server actually reports. Never use verify=False in production: it removes certificate authentication and creates interception risk.

Why does this error appear behind a corporate proxy or VPN?

A proxy-only failure suggests a path-dependent problem, but does not prove interception. DNS, routing and the destination endpoint can also differ.

An HTTP CONNECT tunnel forwards bytes after establishment, as specified in RFC 9110. TLS can remain between the client and destination. An inspecting intermediary instead terminates TLS and presents another certificate.

For authorized inspection, obtain the organization’s CA certificate through verified IT channels. Have administrators confirm which store the failing app uses: browser trust, Windows Trusted Root Certification Authorities, or a separately configured runtime bundle. Do not assume a browser repair also fixes a Python or Java client.

Microsoft documents Group Policy certificate distribution into the selected Windows certificate store. IT should manage deployment; proxy exclusions must follow organizational policy.

For connection setup, see using curl with a proxy. For the routing distinction, see proxy versus VPN. DataImpulse provides proxy infrastructure, not a VPN, scraping API or managed unblocker.

What did our own test show?

We ran the badssl.com test endpoints through five clients on October 15, 2026. Each failure type produced its own error string, which is why the exact code matters. This is a snapshot, not a benchmark.

Method and sample: four badssl.com endpoints tested with five clients, giving 20 recorded client-endpoint outcomes, plus three direct-versus-proxy certificate comparisons and one proxied curl failure. The table summarizes the two trust-error endpoints. These are observed strings, not universal product guarantees.

Through a DataImpulse CONNECT proxy, the SHA-256 certificate fingerprint was identical to the direct connection for untrusted-root.badssl.com and dataimpulse.com: the tunnel passed the original certificate through unchanged, and curl through the proxy failed with the same untrusted-root error as without it.

For www.google.com, fingerprints differed and issuer common names changed from WR2 to WE2; both listed Google Trust Services. Large CDNs such as Google serve different certificates from different edges and regions, so a leaf fingerprint comparison is only meaningful on single-certificate sites. An issuer label alone cannot authenticate a connection, and these observations do not establish a universal non-interception guarantee.

Which platform trust settings matter?

Check the trust configuration used by the failing application. A certificate installed for one client may not resolve another client’s error.

Is it safe to proceed, and how can you verify the certificate first?

Only consider an exception for a controlled development endpoint whose identity you have independently verified. An unexplained public-site warning is a reason to stop.

Chrome documents DevTools, Privacy and security, Security, Overview, View certificate for certificate inspection. Use its security panel guidance to inspect available certificate details. If the blocked page does not expose them, ask the owner or IT to inspect the connection.

Check the hostname, validity period and issuer, then compare the certificate or CA fingerprint through a trusted channel. Recognizing an issuer’s name is insufficient.

Need to compare proxy and direct connections?

If your workflow needs another network path, explore DataImpulse residential proxies. Keep certificate verification enabled on both paths: a proxy can help compare connection behavior, but it cannot repair a broken certificate chain.

Last updated: October 15, 2026.