What does ERR_CERT_AUTHORITY_INVALID mean and why does it happen?

This error occurs when your browser encounters a self-signed certificate that chains to no trusted certificate authority. Since the certificate vouches only for itself and isn't issued by a trusted CA, your browser cannot verify who it's talking to.

How do I fix self-signed certificate warnings on a public website?

Replace the self-signed certificate with a free CA-issued certificate from Let's Encrypt or another ACME provider. These are automatically renewed and fully automatable, so the warning is gone for good once configured.

What's the right way to handle self-signed certificates for internal services?

Run a small internal CA with a trusted root, distribute the root certificate to your devices' trust stores via MDM or config management, then issue normal leaf certificates from that CA. Never train users to click through warnings.

← blog

Self-signed certificate browser warning: how to fix it properly

2026-06-22 · tls · ssl · certificates · self-signed · acme

tlssslcertificatesself-signedacme

A browser shows a warning like NET::ERR_CERT_AUTHORITY_INVALID because a self-signed certificate chains to no trusted certificate authority — it vouches only for itself, so the client cannot verify who it is talking to. The proper fix depends on the audience: for anything reachable on the public internet, replace it with a free, automatically-issued CA certificate (Let's Encrypt or any ACME provider); for internal-only services, add the certificate or your private root CA to the device trust store instead. Clicking "proceed anyway" is never the fix.

Why the warning happens

TLS clients trust a certificate only if it builds a chain up to a CA already in their trust store. A self-signed cert is its own issuer, so there is no chain to a trusted root:

openssl x509 -in cert.pem -noout -subject -issuer
subject= CN = internal.example.com
issuer=  CN = internal.example.com

When subject and issuer are identical and that CN is not a trusted root, the client refuses the cert. This is distinct from an incomplete chain, where the certificate is from a real CA but the server forgot to send the intermediate — that produces a different error and a different fix (send the missing intermediate, not a new cert).

The right fix for public services: ACME

For any host the public can reach, get a real CA certificate. Domain-validated certificates from Let's Encrypt and other ACME CAs are free and fully automatable, so there is no reason to ship self-signed in production. A typical issuance:

certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

ACME clients renew automatically (Let's Encrypt certs last 90 days), so once configured the warning is gone for good and you never touch it manually. Make sure the server then sends the full chain — leaf plus intermediates — to avoid the incomplete-chain problem above.

The right fix for internal-only services

When a service is genuinely internal (a lab box, an appliance, a private CI host) and cannot get a public DV cert, do not click through — install trust explicitly:

Run a small internal CA (an offline root + an issuing intermediate), and distribute the root certificate to every device's trust store via MDM, group policy, or a config-management tool.
Then issue normal leaf certs from that internal CA. Browsers trust them because they now chain to a root the device trusts.
Avoid distributing bare self-signed leaf certs per-host; a single trusted internal root scales far better.

Never train users to bypass warnings

The one fix to rule out is teaching people to ignore the warning. A click-through habit destroys the only signal that distinguishes a misconfiguration from an active man-in-the-middle. Fix the trust path — a real CA outside, your own root inside — so the warning means something again.

Check what your server is presenting →

Frequently asked questions

What does ERR_CERT_AUTHORITY_INVALID mean and why does it happen?: This error occurs when your browser encounters a self-signed certificate that chains to no trusted certificate authority. Since the certificate vouches only for itself and isn't issued by a trusted CA, your browser cannot verify who it's talking to.
How do I fix self-signed certificate warnings on a public website?: Replace the self-signed certificate with a free CA-issued certificate from Let's Encrypt or another ACME provider. These are automatically renewed and fully automatable, so the warning is gone for good once configured.
What's the right way to handle self-signed certificates for internal services?: Run a small internal CA with a trusted root, distribute the root certificate to your devices' trust stores via MDM or config management, then issue normal leaf certificates from that CA. Never train users to click through warnings.