← Blog

ERR_CERT_AUTHORITY_INVALID: find the link Chrome won't trust

2026-09-25

Chrome shows NET::ERR_CERT_AUTHORITY_INVALID when it can’t trace the site’s certificate back to a root certificate it trusts. Usually the site is serving a certificate no public CA issued, or something on the network replaced the real certificate with its own. Less often, the CA itself has lost Chrome’s trust. One openssl command tells you which.

If you’re a visitor and the site is one you’d log in to, don’t click through the warning. The only case where the fix is yours is when your own antivirus or your company’s network is causing it, covered below.

What Chrome is checking

Every certificate names an issuer. Chrome follows that chain of issuers until it reaches a root certificate in its trust list. If the chain ends somewhere Chrome doesn’t know, you get this error.

The trust list is Chrome’s own. Chrome switched from the operating system’s list to the Chrome Root Store, enabled by default from Chrome 108 on Windows and macOS and from Chrome 114–115 on Linux, ChromeOS, and Android. Chrome on iOS still uses Apple’s trust list. Roots you or your IT team install on the device are still honored.

Two nearby errors have different causes. A certificate that doesn’t list the hostname you typed gives ERR_CERT_COMMON_NAME_INVALID. One past its end date gives ERR_CERT_DATE_INVALID. This one is about who signed the certificate.

See the chain the server sends

Run this against the hostname that shows the error, from the same network where you see it:

openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com </dev/null 2>/dev/null \
  | grep -E '^ *[0-9] s:|^ *i:|Verify return code'

Output for that test host:

 0 s:C=US, ST=California, L=San Francisco, O=BadSSL, CN=*.badssl.com
   i:C=US, ST=California, L=San Francisco, O=BadSSL, CN=BadSSL Untrusted Root Certificate Authority
 1 s:C=US, ST=California, L=San Francisco, O=BadSSL, CN=BadSSL Untrusted Root Certificate Authority
   i:C=US, ST=California, L=San Francisco, O=BadSSL, CN=BadSSL Untrusted Root Certificate Authority
    Verify return code: 19 (self-signed certificate in certificate chain)

Each s: line is a certificate the server sent, and the i: line under it is who signed it. The last line is OpenSSL’s verdict. The same command works with the LibreSSL openssl that ships with macOS; it prints the names with slashes instead of commas.

OpenSSL checks against its own trust list, not Chrome’s, so the two can disagree. Read the return code together with the issuer names.

Match the return code to the cause

We ran the badssl.com test hosts through both OpenSSL 3.6 and Chromium 147 on macOS. The codes below come from that test.

18 or 19: self-signed, or signed by a private CA

18 (self-signed certificate) means the certificate signed itself. 19 (self-signed certificate in certificate chain) means the chain ends at a root nobody outside your organization trusts. Chrome showed ERR_CERT_AUTHORITY_INVALID for both.

For a public site, replace the certificate with one from a public CA. Let’s Encrypt issues them free, and most hosting platforms and CDNs will set one up for you. For an internal tool on a private CA, install that CA’s root on the devices that need it, through your device management or group policy. Teaching staff to click through the warning trains them to do it on a real attack.

21: a missing intermediate certificate, and Chrome may not care

21 (unable to verify the first certificate) means the server sent its own certificate without the intermediate that connects it to a root. Nearly every guide to this error lists it as a cause. In our test Chrome loaded incomplete-chain.badssl.com without any warning; Chrome can fetch a missing intermediate on its own. Firefox doesn’t fetch intermediates, but it preloads the ones public CAs have disclosed, which covers most cases.

So if Chrome on a desktop shows this error, a missing intermediate is probably not the reason. Fix it anyway. Not every client is that forgiving: openssl failed against the same host. Configure the server with the full chain (with Certbot, that’s fullchain.pem, not cert.pem).

Clients can also disagree the other way. When the old AddTrust root expired on May 30, 2020, updated browsers kept working while older OpenSSL-based clients failed on the same servers.

0 but Chrome still refuses: a CA that Chrome stopped trusting

0 (ok) means OpenSSL trusts the chain. If Chrome still shows the error on the same network, look at the issuer’s organization. Chrome can stop trusting a CA whose roots are still in the list OpenSSL uses.

The best-known case is Entrust. Chrome stopped trusting Entrust and AffirmTrust certificates issued after November 11, 2024, starting with Chrome 131; older certificates kept working until they expired. Chrome reports the rejected ones as ERR_CERT_AUTHORITY_INVALID: its certificate verifier treats a certificate that fails a root’s distrust date the same way as one from an unknown root. Chunghwa Telecom and NetLock followed: Chrome 139 and later reject their certificates issued after July 31, 2025. To check a site, open the certificate viewer from the address bar and read the Organization under “Issued By”. If it names one of these CAs, move to another CA.

10: not this error

10 (certificate has expired) is a date problem. Chrome shows ERR_CERT_DATE_INVALID for it, not ERR_CERT_AUTHORITY_INVALID. Renew the certificate.

When only one device or network gets the error

If the command returns 0 from your laptop at home but a user still sees the error, run it again from their network. A different issuer in the i: line means something in between is answering with its own certificate.

  • Firewalls that inspect HTTPS. Behind a FortiGate with deep inspection, the firewall signs replacement certificates with its own CA. Devices that don’t have that CA installed show this error, and the issuer is the firewall rather than the site’s CA
  • Antivirus that scans HTTPS. Kaspersky Endpoint Security adds its own certificate to the Windows certificate store and creates its own certificates to scan traffic, so the issuer you see is Kaspersky rather than the site’s CA. Chrome accepts them only while that Kaspersky certificate is in the store; on a device where it’s missing, the result is this error

In both cases, the certificate your server sends is fine and the fix belongs to whoever runs the device or network. Clearing the browser cache, removing extensions, or restarting Chrome doesn’t change which certificate arrives. That advice appears in most guides to this error and rarely helps.

Where Certly fits

Certly monitoring checks the certificate your server actually serves and alerts before it expires. It doesn’t validate the trust chain, so it won’t alert you to this error. Use the openssl command above for that.

The free checker reads public Certificate Transparency logs and shows the issuer and expiry of the most recent certificate issued for your hostname. Publicly trusted CAs log what they issue; self-signed and private-CA certificates never appear there. If the checker shows a current certificate from a public CA but visitors see this error, compare it with what the server or the network is actually handing out.

The free plan covers two sites with email alerts; paid plans add Slack, Discord, and webhook alerts.

Sources