ERR_CERT_AUTHORITY_INVALID: Causes and Fixes | FortifyNet

ERR_CERT_AUTHORITY_INVALID means the browser could not build a chain of trust from the certificate your server presented back to a root certificate authority it already trusts. Chrome shows it as NET::ERR_CERT_AUTHORITY_INVALID under a "Your connection is not private" screen. It is almost never a sign that your certificate has expired, and almost always one of two things: your server is not sending its intermediate certificate, or the certificate was not issued by a publicly trusted CA at all. The fix takes minutes once you know which side the fault is on.

What the error actually means

Every TLS certificate is validated by walking a chain. The browser receives your server (leaf) certificate, reads which CA signed it, and looks for that CA. If the signing CA is an intermediate, the browser needs that intermediate certificate too, so it can check who signed that, and keep walking until it reaches a root certificate that is already installed in its trust store.

If any link in that walk is missing, unsigned by a trusted party, or issued by a CA the browser has removed, the chain cannot be completed and the connection is refused with ERR_CERT_AUTHORITY_INVALID.

Chrome ships its own trust list, the Chrome Root Store, rather than relying only on the operating system. Firefox does the same. Safari and Edge lean on the OS store. That difference is why a site can fail in one browser and load in another on the same machine, and it is one of the most useful diagnostic signals you have.

The seven causes, and where the fault lies

Causes 1 and 2 account for the overwhelming majority of real reports. If you own the site, start there.

The 30-second triage

Before changing anything, work out whether the problem lives on the server or on the visitor's machine.

1. Open the site on mobile data, on a phone that has never visited it. If it fails there but works on your desktop, you have a missing intermediate. Desktop browsers cache intermediates they have seen before and can silently repair a broken chain, which is exactly why this bug survives so long undetected.
2. Try a second browser on the same machine. Failing in Chrome only points at the Chrome Root Store rejecting the CA. Failing everywhere on one machine points at interception or an outdated device.
3. Click the warning, then "Advanced", and read the issuer. If the issuer is your antivirus product, a firewall vendor, or your employer's name, traffic is being intercepted and re-signed. That is cause 4, and it is not your website's fault.
4. Check the chain from the command line with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com -showcerts

You should see at least two certificates in the output: your leaf, then one or more intermediates. If only one certificate comes back, the intermediate is missing and you have found the bug.

Fix 1: install the full certificate chain

This is the single most common server-side cause. Your CA issues you a leaf certificate and one or more intermediates, and your server has to send all of them. Point your web server at the full chain file rather than the leaf alone.

If you use Let's Encrypt, the fix is usually a one-word change: use fullchain.pem, never cert.pem. Let's Encrypt notes that every certificate it issues has an intermediate directly signed by its most widely trusted root, and that multiple active intermediates rotate over time, so hard-coding a specific intermediate file is fragile (Let's Encrypt, Chains of Trust). Reload the server after the change; a config change alone does nothing until the process picks it up.

Fix 2: replace a self-signed certificate

A self-signed certificate signs itself. No public CA vouches for it, so no browser can ever trust it without manual intervention. This is correct behaviour, not a bug.

For anything public-facing, get a free certificate from a publicly trusted CA and automate renewal. For genuinely internal tools, either add your internal root to the trust stores of the devices that need it, or issue from an internal CA that is already distributed by your device management. Do not train your team to click through the warning; that habit is precisely what phishing operators rely on.

Fix 3: rule out interception and stale devices

If the issuer shown in the warning is an antivirus product, temporarily disable its HTTPS or SSL scanning feature and reload. Many security suites insert their own root to inspect encrypted traffic, and a broken or expired inspection root breaks every HTTPS site at once.

On an outdated device, install pending OS updates. Root stores ship with system updates, and a device several years behind will be missing newer roots entirely. Finally, confirm the clock: a system date that is wildly wrong can make a valid root look not-yet-valid, which surfaces as an authority error rather than a date error.

Fix 4: check whether your CA is still trusted

Root programs remove CAs that fail their requirements, and those removals are real events with real deadlines. The Chrome Root Program requires that from 15 June 2026, newly issued public TLS certificates carry only the serverAuth extended key usage; certificates that also carry clientAuth will no longer be trusted by Chrome, and CA owners whose hierarchies do not comply must restructure or exit the store (Chrome Root Program Policy).

If a site suddenly fails in Chrome while older clients still accept it, a distrust event is a realistic explanation. The remedy is to reissue from a compliant CA.

Why this error is about to get more common

Certificate lifetimes are collapsing. Under CA/Browser Forum ballot SC-081v3, adopted in April 2025, the maximum validity period steps down from 398 days to 200 days on 15 March 2026, to 100 days in 2027, and to 47 days in 2029 (CA/Browser Forum, Ballot SC-081v3).

Maximum TLS certificate lifetime under CA/Browser Forum ballot SC-081v3. Source: CA/Browser Forum, April 2025.

More renewals mean more chances for an automation script to deploy a leaf without its intermediate. Every renewal is now a deployment, and every deployment can break the chain. Teams that renewed manually once a year and never thought about it again will hit this error for the first time in 2026.

Verifying the fix

After changing the chain, do not trust your own browser. It has cached the intermediate and will show you a green padlock over a chain that still fails for everyone else. Verify from a clean vantage point: an external scanner, a phone on mobile data, or a fresh browser profile. Confirm that the leaf and every intermediate are being served, and that no intermediate is itself expired.

Related guides

• "Your connection is not private": what it means and how to fix it covers the wider warning screen this error appears under.
• ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it handles the handshake-level failures that look similar but have different causes.
• SSL/TLS certificate security: the complete guide to an A+ rating walks through chain, protocol and cipher configuration end to end.

FAQ

Is ERR_CERT_AUTHORITY_INVALID dangerous for visitors?
It can be. The browser is telling you it cannot verify who it is talking to, which is exactly the condition a machine-in-the-middle attack creates. On a site you do not control, treat the warning as real and do not proceed.

Why does the site work on my computer but not for my customers?
Desktop browsers cache intermediate certificates from previous visits and can complete a broken chain from memory. Devices that have never seen the intermediate cannot. This asymmetry is the classic signature of a missing intermediate.

Does clearing the browser cache fix it?
Rarely, and only when the fault is on the device. If the chain is broken on the server, clearing the cache changes nothing for anyone.

How is it different from ERR_CERT_COMMON_NAME_INVALID?
AUTHORITY_INVALID means the issuer cannot be trusted. COMMON_NAME_INVALID means the issuer is trusted but the certificate was issued for a different hostname than the one being visited.

Can I just click through the warning?
On your own staging server, yes. On any site handling real data, no. Clicking through disables the exact protection that would tell you the connection had been tampered with.

Check your chain before your visitors do

A missing intermediate is invisible from your own desk and obvious to every new visitor. Run a free FortifyNet scan and see your full certificate chain, protocol support, security headers, DNS and email authentication in about 60 seconds. No signup required.

Sources: CA/Browser Forum, Ballot SC-081v3; Chrome Root Program Policy; Let's Encrypt, Chains of Trust.

Originally published at fortifynet.com/blog/err-cert-authority-invalid. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.