How to Fix NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID means the browser doesn't trust who issued the certificate — it's self-signed, from an unknown CA, or the intermediate chain is missing. Owners install the full chain from a trusted CA (or fix the intermediate); visitors should not proceed on sensitive sites.

What does this error actually mean?

When you connect to a site over HTTPS, the server presents a certificate. The browser checks two things: that the certificate matches the domain, and that it was issued by a Certificate Authority (CA) the browser already trusts.

ERR_CERT_AUTHORITY_INVALID is the second check failing. The certificate may be perfectly valid and unexpired, but the browser cannot trace it back to a trusted root, so it refuses to vouch for the connection. The path-building rules browsers follow here are specified in RFC 5280, the X.509 certificate and chain-validation standard.

There are three common causes, and they look identical to a visitor:

• Self-signed certificate. The server generated and signed its own certificate. No external authority vouches for it, so no browser trusts it by default. Common on internal tools, routers, NAS devices, and local development.
• Unknown or untrusted CA. The certificate was issued by a CA that isn't in the browser's trust store — a private internal CA, a regional authority, or one that was distrusted.
• Missing intermediate certificate. The certificate comes from a perfectly trusted CA, but the server only sends the leaf certificate and omits the intermediate certificates that link it to the trusted root. The chain is broken, so the browser can't complete the path.

That last cause is the one that catches site owners off guard, because the certificate is genuinely fine — only the way the server presents it is wrong.

If you're just visiting

If you're a visitor and not the site owner, an untrusted issuer is a meaningful signal. The browser is telling you it cannot confirm who really controls the certificate. That doesn't always mean an attack is underway — but it does mean the usual guarantee that you're talking to the real site has not been established.

Why "Proceed anyway" is riskier here

Some certificate warnings are mild (for example, a certificate that expired yesterday on a site you visit constantly). This one is different. An untrusted issuer is exactly the state a network attacker would produce if they intercepted your traffic and presented their own certificate.

If you proceed on a login page, a banking site, or anything where you enter personal data, you may be handing that data to whoever issued the certificate. On sensitive sites, do not click through — close the tab and reach the service another way.

Corporate proxies and antivirus root injection

There is one routine, benign cause worth knowing about. Many corporate networks and some antivirus products perform TLS inspection: they intercept HTTPS, decrypt it, scan it, then re-encrypt it with their own certificate.

For this to work without warnings, IT installs a custom root certificate into every managed device's trust store. On a properly managed machine you never see an error. But if that root isn't installed — a personal device on the office Wi-Fi, a fresh profile, or a browser that uses its own trust store — every site suddenly throws ERR_CERT_AUTHORITY_INVALID, because the proxy's issuer is unknown to you.

If only your work network is affected and your IT team confirms inspection is in place, that explains it. If you see it on a public network you don't control, treat it as a red flag, not a formality.

If you own the site

If this is your site, the fix is almost always about the certificate chain you serve. Work through these in order.

Use a publicly trusted CA

A self-signed certificate, or one from a private CA, will never be trusted by visitors' browsers unless they manually install your root — which is fine for internal tooling but wrong for a public site. Get a certificate from a publicly trusted authority.

The free, widely supported option is Let's Encrypt, typically issued automatically through a client like certbot. Once issued, a Let's Encrypt certificate chains to a root that every mainstream browser already trusts.

Install the full chain, not just the leaf

The single most common owner-side cause of this error is serving only the leaf (your domain's) certificate and forgetting the intermediates. The browser needs the complete path: leaf → intermediate(s) → trusted root. The root lives in the browser; you must supply the leaf and every intermediate. Most CAs give you two files — and choosing the wrong one is the trap. With Let's Encrypt you get:

• cert.pem — the leaf certificate only. Serving this alone breaks the chain.
• fullchain.pem — the leaf plus the intermediates. This is the one to serve.

Configure the chain correctly in nginx

In nginx the ssl_certificate directive must point at the file that contains the full chain, in the right order — leaf first, then intermediates:

server {
    listen 443 ssl;
    server_name example.com;

    # Use fullchain.pem (leaf + intermediates), NOT cert.pem
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Order matters: the leaf certificate must come first in the file, followed by each intermediate up the chain. The trusted root is not included — clients already have it. After editing, reload nginx (nginx -t && systemctl reload nginx) and verify the chain rather than assuming it's fixed.

Why does it work in Firefox but fail in Chrome?

For the full map of certificate and TLS errors, see the pillar guide on SSL/TLS errors. If you arrived here from the generic browser warning, the companion article on "Your connection is not private" explains the same situation from the visitor's side.