ERR_CERT_AUTHORITY_INVALID: Untrusted Certificate Fix Guide

NET::ERR_CERT_AUTHORITY_INVALID means the certificate chain the server presented does not lead to a root that your browser or operating system trusts. The certificate may be perfectly valid in dates and name, but the browser cannot find a trusted signer behind it. Chromium browsers show it under "Your connection is not private." Firefox shows SEC_ERROR_UNKNOWN_ISSUER, and Safari says the certificate is not trusted or was signed by an unknown authority.

Three situations account for nearly every case: a self-signed certificate, a chain with a missing intermediate, or something on the visitor's side replacing the certificate (corporate proxy, antivirus, captive portal).

If you are a visitor

1. Look at who issued it. Click the warning's Advanced link, then view the certificate. If the issuer is the same as the subject, it is self-signed. If it names your employer, school or an antivirus vendor, a local inspection tool is replacing the site's certificate.
2. Check for a captive portal. Hotel, airport and cafe Wi-Fi often intercept HTTPS until you sign in. Open a plain http:// page to trigger the login screen.
3. Check your clock. Wrong dates can also break trust. See ERR_CERT_DATE_INVALID.
4. Update your OS and browser. Older systems lack newer root certificates. A device that stopped getting updates years ago may reject sites that anyone else can open.
5. Try a different network. If the error disappears on mobile data, the interception is on the first network.
6. Do not click through on banking, shopping or login pages. A certificate from an unknown authority is exactly what an attacker on the network would present.

If you own the site

Self-signed certificates

Generated with openssl req -x509, these are signed by themselves, so no browser trusts them. They are fine for a private test host if you import them deliberately, but not for public traffic. Replace with a free certificate from an ACME provider:

sudo certbot --nginx -d example.com -d www.example.com

Missing intermediate certificate

This is the most frequent mistake on real sites. You installed only the leaf certificate, so clients that have not cached the intermediate cannot build the path to a root. It often works on your own computer (which has cached the intermediate) and fails for others and for command-line tools.

Serve the full chain, leaf first, then intermediates:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;  # not cert.pem
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

For Apache 2.4.8 and later, point SSLCertificateFile at the full chain file. Older versions use SSLCertificateChainFile for the intermediates.

Test what the server actually sends:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Look at the "Certificate chain" section. You should see the leaf at depth 0 and an intermediate at depth 1. If you see only depth 0 and a "unable to verify the first certificate" message, the intermediate is missing.

Wrong or outdated chain

If a CA changes its intermediates and you keep an old bundle, some clients fail. Download the current bundle from your CA rather than reusing a file from a previous renewal. If you use cross-signed chains for old Android compatibility, confirm your CA still publishes them.

Private or corporate CA

An internal CA's root is not in public trust stores. Distribute the root to managed devices via group policy or MDM. Public websites must not use an internal CA.

Distrusted or revoked issuers

Browser vendors occasionally remove trust in a CA. If the issuer has been distrusted, you must reissue from another CA; reinstalling the same certificate will not help. Check your CA's announcements if a previously working certificate suddenly fails everywhere.

A CDN or proxy served the wrong certificate

If you recently changed DNS to point at a new host, the new host may present its default or placeholder certificate. Check that the hostname is added and that certificate issuance has completed on the new platform.

Confirm the fix

1. Run the SSL Chain Debugger. It flags a missing intermediate, wrong order and untrusted roots.
2. Run the SSL Checker for expiry, issuer and the hostnames covered.
3. Check from a clean environment too: curl -v https://example.com/ on a server that has never visited your site should return without a verification error. A cached intermediate on your own machine can hide a broken chain.
4. Monitor with the uptime monitor so certificate problems alert you before visitors notice.

Next steps

• See the SSL/TLS certificate errors guide for how trust is evaluated.
• Learn about certificate types in SSL certificate types explained.
• If the warning is about the hostname rather than the issuer, read ERR_CERT_COMMON_NAME_INVALID.
• For the generic warning screen, see Your connection is not private.

FAQ

Why does the site work on my computer but not for customers?

Your browser likely cached the intermediate certificate from an earlier visit, so it can complete the chain. Visitors without that cache cannot. Serve the full chain.

Is a self-signed certificate ever fine?

For internal development, yes, if you import it into your own trust store. For a public site, no: every visitor will see this warning.

Why do I get this warning only at work?

A corporate security gateway may decrypt and re-sign traffic with its own CA. If your device lacks that CA, or a personal device is not enrolled, the browser reports an authority error.

Will clicking "Proceed" harm my computer?

Not by itself, but you would be trusting a connection the browser cannot verify. Avoid it for anything involving passwords, payment or personal data.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.