Why does the error show on some devices but not others?

That's the signature of a missing intermediate certificate. Devices that happen to have cached the intermediate can build the chain; devices that haven't can't, so they fail. Installing the full chain on the server fixes it everywhere.

Is ERR_CERT_AUTHORITY_INVALID the same as an expired certificate?

No. Expiry usually produces ERR_CERT_DATE_INVALID. Authority-invalid means the browser can't trust the issuer or build a chain to a trusted root, which is a trust and chaining problem, not a timing one.

Can I just click through the warning?

You can for your own testing, but never tell visitors to. The warning means the connection's identity can't be verified, so bypassing it is a real security risk. Fix the underlying certificate instead.

How to Fix NET::ERR_CERT_AUTHORITY_INVALID

VigilDog Team · September 9, 2026 · 6 min read

NET::ERR_CERT_AUTHORITY_INVALID stops visitors cold with a full-page "Your connection is not private" warning. The message sounds alarming but the cause is usually specific and fixable: the browser can't build a trusted chain from your certificate up to a root it recognizes. Here's exactly what triggers err_cert_authority_invalid and how to resolve it, whether the problem is on your server or your machine.

What the error actually means

Every HTTPS certificate is validated by chaining it upward: your site's leaf certificate is signed by an intermediate certificate, which is signed by a root certificate that browsers and operating systems ship with and trust. If the browser can walk that chain all the way to a trusted root, the padlock appears. If it can't, you get ERR_CERT_AUTHORITY_INVALID: the authority that issued the cert can't be verified.

Note the difference from date errors. If the certificate has expired you'll typically see ERR_CERT_DATE_INVALID instead. Authority-invalid is specifically about trust and chaining, not time, though a badly configured server can produce either.

The TLS certificate chain of trust

The common causes

Most real-world cases come down to a short list, and identifying which one you have tells you exactly where to fix it.

Missing intermediate certificate: the server sends only the leaf, so the browser can't reach a trusted root. This is the number-one cause and shows up on some devices but not others.
Self-signed certificate: nothing signed it but itself, so no trusted root exists. Fine for local testing, fatal in production.
Certificate from an untrusted or private CA: common with internal corporate CAs whose root isn't installed on the visiting machine.
A corporate proxy or antivirus intercepting HTTPS with its own root that your device doesn't trust.
An outdated OS or browser missing newer root certificates, or a wrong system clock breaking validation.

Fix it on the server (the usual fix)

If the error appears for outside visitors, the problem is almost always a missing intermediate chain. First confirm what your server is actually sending:

Run openssl s_client -connect yourdomain.com:443 -showcerts and look at the certificate chain it returns. If you see only your leaf certificate and no intermediate, that's your culprit. The fix is to install the full chain: most certificate authorities provide a bundle (often fullchain.pem or a ca-bundle file). Configure your server to serve the leaf followed by the intermediate(s), in that order, then reload.

On nginx, point ssl_certificate at the combined fullchain file rather than the bare cert. On Apache, set SSLCertificateFile to the leaf and SSLCertificateChainFile (or include the chain in the cert file for newer versions) to the intermediates. After reloading, verify with an external scanner so you're testing a fresh connection, not a cached one. The free SSL checker will confirm the chain resolves cleanly from the outside.

When the fix is on the client side

If the error only appears on one machine while everyone else loads the site fine, the certificate is probably valid and the issue is local. Work through these quickly.

Check the system clock and time zone; a wrong date breaks chain validation.
Update the browser and operating system to pull in current root certificates.
Test in an incognito window and with extensions disabled to rule out interference.
Check whether antivirus or a corporate proxy is doing HTTPS inspection; its root may need to be installed or the feature disabled.
For an internal site behind a private CA, install that CA's root certificate in the OS trust store.

Stop it from coming back

Chain problems love to reappear: a renewal script that only fetches the leaf, a cert swap that drops the intermediate, or an expiry nobody watched. The pattern is always the same, a silent change that surfaces as a browser warning your customers see before you do.

VigilDog checks your certificate chain and expiry continuously and warns you well ahead of trouble, so a missing intermediate or an approaching renewal never becomes a public outage. Use the SSL checker to fix today's error, and see continuous SSL monitoring to make sure the next one never ships. If you're also chasing an expiry, our guide on an expired SSL certificate covers that path.