Fix NET::ERR_CERT_AUTHORITY_INVALID

The page is blocked and Chrome says:

Your connection is not private
NET::ERR_CERT_AUTHORITY_INVALID

The certificate exists, it is for the right hostname, and it has not expired. What the browser is telling you is narrower than "this certificate is bad." It is saying: I cannot build a chain of trust from this certificate up to a root certificate authority I already trust. The authority that issued it is, as far as this browser is concerned, unknown.

What "authority invalid" actually means

Browsers ship with a built-in list of trusted root CAs. A certificate is trusted only if the browser can connect it, link by link, up to one of those roots: leaf → intermediate → root. When that path cannot be built, you get this error. There are only a few ways it happens.

The certificate is self-signed. It was issued by itself, not by a recognized CA. There is no path to any trusted root because the certificate is its own issuer. Common on internal services, dev environments, routers, and appliances.

It was signed by a private or internal CA. Many companies run their own CA for internal systems. That CA root is trusted on managed company machines (it was pushed to their trust stores) but is unknown on any other device, which then shows this error.

The intermediate certificate is missing. The leaf was issued by a real public CA, but the server is not sending the intermediate that links it to the root. The browser usually papers over this by fetching the intermediate itself, but when it cannot, you see an authority error. This overlaps with the classic incomplete chain problem.

The issuing CA is genuinely not trusted, for example a CA that was distrusted and removed from browser root stores, or a brand-new CA not yet widely distributed.

How to tell which one it is

Look at the certificate's issuer. If the issuer equals the subject, it is self-signed. If the issuer is a company or internal name you recognize, it is a private CA. If the issuer is a known public CA (Let's Encrypt, DigiCert, Sectigo) yet the browser still complains, the chain is almost certainly incomplete.

To see the issuer and the chain the server presents without decoding anything by hand, run the host through the SSL checker; it reports the issuer and flags a self-signed certificate or a missing intermediate explicitly. If you have the certificate file rather than a live host, the SSL decoder parses it in the browser and shows issuer, subject, and validity locally without uploading it.

The fix depends on the cause

Self-signed certificate on something you control: for anything public-facing, replace it with a certificate from a trusted CA — Let's Encrypt is free and automatable. Self-signed is fine only for local development, and even there, prefer a tool that creates a locally-trusted dev CA so you are not training yourself to click through warnings.

Private/internal CA: the certificate is fine; the client just lacks the CA root. Distribute your internal CA root certificate to the machines and browsers that need it through your device management. Do not weaken the server to public CAs if the service is genuinely internal.

Missing intermediate: the certificate is fine; the server configuration is wrong. Serve the full chain — leaf followed by intermediates — so every client can build the path. Most servers want a fullchain.pem rather than just the leaf.

Distrusted or unknown public CA: reissue from a CA that is currently in the major root programs.

A warning worth stating plainly: never train people to click "Proceed anyway" on this error for a public site. That is exactly what an interception attack looks like. Fix the trust path instead, then confirm it by running the host through the SSL checker to check yours.