How is this different from NET::ERR_CERT_COMMON_NAME_INVALID?

AUTHORITY_INVALID means the chain does not reach a trusted root — a missing intermediate, a self-signed cert, or a private CA. COMMON_NAME_INVALID means the chain is trusted but the hostname does not match the certificate.

Why does it fail for only some visitors?

A missing intermediate is intermittent. Clients that already cached that intermediate from another site can build the chain and succeed, while fresh clients cannot and see the error.

Is reinstalling the certificate enough to fix it?

Only if you install the full chain. Re-issuing or reinstalling the leaf alone, without the intermediate, reproduces the same error.

Views: 11

NET::ERR_CERT_AUTHORITY_INVALID Fix

NET::ERR_CERT_AUTHORITY_INVALID: the cert won't trace to a trusted root. Fix in 3 checks: chain, self-signed, private CA. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome shows NET::ERR_CERT_AUTHORITY_INVALID and blocks the page with “Your connection is not private.” The certificate exists, but the browser will not trust who issued it.

Symptoms

Chrome reports NET::ERR_CERT_AUTHORITY_INVALID; Firefox shows SEC_ERROR_UNKNOWN_ISSUER; Safari says the certificate is not trusted.
Some browsers or devices accept the site while others reject it.
openssl s_client -connect host:443 -showcerts returns only one certificate.

Top 3 Causes

Missing intermediate certificate - The server sends only the leaf, so the browser cannot build a path from the certificate to a trusted root. This is the most common cause, and it is intermittent: clients that cached the intermediate elsewhere succeed, others fail.
Self-signed certificate - No public CA was involved. Self-signed certs are fine for internal or staging use, but public browsers never trust them.
Issued by a private or untrusted CA - A corporate root, an antivirus or proxy intercepting TLS, or any CA not in the browser’s root store.

Diagnose with DechoNet

SSL Check to see whether the full chain is served and resolves to a trusted root.
HTTP Check to confirm the final HTTPS response once the chain is fixed.

Resolution Checklist

Run openssl s_client -connect host:443 -showcerts. You should see the leaf plus at least one intermediate. If only one certificate appears, the chain is incomplete.
Deploy the full chain file (often fullchain.pem), not just the leaf certificate.
Replace self-signed certificates with a CA-issued one; Let’s Encrypt is free and trusted by default.
If a private CA is intentional, distribute its root to every client’s trust store — do not expect public browsers to trust it.
Re-run SSL Check after deploying the chain to confirm it resolves to a trusted root.

When to Escalate

Escalate to your managed hosting or CDN provider if you cannot control which certificate bundle is served.
If a corporate proxy or antivirus is injecting its own CA, that is a managed-device policy issue, not a server-side fix.