# NET::ERR_CERT_AUTHORITY_INVALID: causes and fixes

> NET::ERR_CERT_AUTHORITY_INVALID means Chrome does not trust the certificate's issuer: self-signed, private CA, missing chain or interception.

Source: https://ssl.sh/errors/net-err-cert-authority-invalid/
Last updated: 2026-11-10

**NET::ERR_CERT_AUTHORITY_INVALID means the certificate was not issued by an authority Chrome trusts.** On a single website it usually points to a self-signed, private-CA or incompletely chained certificate. On every website it almost always points to software or a network device intercepting your HTTPS traffic.

## Is it the site or your device?

One failing site points to its certificate; every site failing points to interception on your device. Check the site from outside your network with the [SSL checker](https://ssl.sh/tools/ssl-checker/) or:

```bash
curl ssl.sh/example.com
```

- **The checker reports "untrusted issuer" or "self-signed":** the site is at fault. As a visitor, do not bypass the warning on a site that asks for a login or payment.
- **The checker reports a trusted chain:** something local is replacing the certificate. In Chrome, click the "Not secure" label, open the certificate viewer and read the **Issued By** field. If it names an antivirus product, your company, or something you do not recognise, the interception is happening on your device or network.

## Causes

### 1. Self-signed or private-CA certificate

Routers, NAS boxes, staging servers and intranet apps often ship with a self-signed certificate or one from an internal CA. Confirm with:

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer
```

If subject and issuer are identical, the certificate is self-signed. Fix: issue a publicly trusted certificate (free from any ACME CA) for anything public; for internal systems, have IT deploy the internal root through device management.

### 2. The chain cannot be built

The server sends only the leaf certificate and the client cannot fetch the intermediate. Chrome usually repairs this itself, but not always (for example when the AIA URL is unreachable). Rebuild the chain with the [chain builder](https://ssl.sh/tools/chain-builder/).

### 3. Antivirus or corporate HTTPS interception

Products that scan HTTPS install their own root certificate. If the root is not in Chrome's view of trusted roots, or the product generates broken certificates, every site fails. See [antivirus HTTPS scanning](https://ssl.sh/errors/antivirus-https-scanning-ssl-error/) and [corporate SSL inspection](https://ssl.sh/errors/corporate-ssl-inspection/).

### 4. A root that Chrome distrusted or does not include

Chrome's root store differs from Windows and macOS. A CA that is distrusted by Chrome, or a root only present in an operating system store, can cause this error in Chrome alone. Check the issuing CA against the [Chrome Root Program Policy](https://www.chromium.org/Home/chromium-security/root-ca-policy/) and switch CA if needed.

### 5. Outdated device

Old operating systems may lack newer roots. On those devices update the system, or use a browser that ships its own root store.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge | "Your connection is not private" with `NET::ERR_CERT_AUTHORITY_INVALID` |
| Firefox | [SEC_ERROR_UNKNOWN_ISSUER](https://ssl.sh/errors/sec-error-unknown-issuer/) or [MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT](https://ssl.sh/errors/mozilla-pkix-error-self-signed-cert/) |
| Safari | "This Connection Is Not Private"; details say the certificate is not trusted |
| Android apps | `Trust anchor for certification path not found` ([details](https://ssl.sh/errors/android-trust-anchor-not-found/)) |
| curl | `SSL certificate problem: unable to get local issuer certificate` |

## How site owners fix it

A publicly trusted certificate served with its full chain fixes it.

**1. Use a publicly trusted certificate.** For any site visited by the public, replace self-signed or internal certificates with one from a public CA. With certbot:

```bash
sudo certbot --nginx -d example.com -d www.example.com
```

**2. Serve the full chain.** Point Nginx at the full-chain file, not the leaf alone:

```nginx
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
```

For Apache 2.4.8 and later, `SSLCertificateFile` should also contain the leaf followed by the intermediates.

**3. Verify from outside.** Run `curl ssl.sh/example.com` again; the chain should end at a trusted root with no warnings. Test in Firefox and with `curl` as well, because Chrome's automatic repair can hide a broken chain.

**4. For internal sites,** distribute your CA root through Group Policy, MDM or configuration management instead of asking users to click through warnings.
