1. Bridge SSL
  2. Errors
  3. ERR_CERT_AUTHORITY_INVALID: what it means and how to fix it

ERR_CERT_AUTHORITY_INVALID: what it means and how to fix it

7 min readUpdated Aug 2026
Your browser received a certificate it cannot trace back to an authority it trusts. Either the certificate genuinely came from an untrusted source, or it came from a trusted one and the server failed to send the intermediate certificates that prove it. The second is far more common. Firefox shows the same fault as SEC_ERROR_UNKNOWN_ISSUER.

Quick facts

BrowsersChrome, Edge, and other Chromium browsers
Exact textYour connection is not private with NET::ERR_CERT_AUTHORITY_INVALID
Layercertificate trust chain
Who fixes itusually the site owner; occasionally the visitor

What this error means

Trust in a certificate is not a property of the certificate itself. It comes from a chain: your browser trusts a small set of root authorities, those roots vouch for intermediate authorities, and intermediates issue the certificate a site presents.

The browser must be able to follow that chain from the certificate it received up to a root it already trusts. This error means it could not. Three situations produce that outcome, and they need different responses.

Fixes by cause

The server is not sending its intermediate certificates

This is the most frequent cause by a wide margin, and the most counterintuitive, because the certificate is entirely valid.

A server must present its own certificate and the intermediates connecting it to a root. If it sends only its own, browsers that have previously cached the intermediate connect without complaint, and browsers that have not show this error. That is why the site appears to work for some visitors and not others, and why "it works on my machine" proves nothing here.

  • Owner fix

    Reconfigure the server to serve the full chain. Certificate authorities supply a bundle for exactly this purpose, and most server software has a specific setting or file for it. After changing it, verify from a machine that has never visited the site.

  • Visitor workaround

    None. This is entirely the site's to fix.

The certificate is self-signed

A certificate issued by nobody in particular. Common on internal systems, development environments, and appliances that ship with one.

  • Owner fix

    For anything public, obtain a certificate from a recognised authority. Self-signed certificates are appropriate for internal use where you can distribute the certificate deliberately, and they are never appropriate for a public site.

  • Visitor action

    If this is a device on your own network, the error is expected. If it is a public site, treat the warning as accurate.

A proxy or antivirus is intercepting the connection

Corporate networks and some security software intercept encrypted traffic by presenting their own certificate. This is a deliberate arrangement in managed environments and is supposed to be accompanied by installing the intercepting authority on the device.

When that installation has not happened, or when consumer antivirus does it uninvited, every site shows this error. The distinguishing symptom is breadth: one site failing points elsewhere, but many unrelated sites failing at once points here.

Visitor fix On a corporate device, this is for your administrators. On a personal device, look at whether security software has an HTTPS scanning feature enabled, and consider whether you want it.

Browser variants

Firefox reports the same underlying failure as SEC_ERROR_UNKNOWN_ISSUER, with wording about the issuer not being recognised. Safari describes it in words rather than with a code, usually mentioning that the certificate is not trusted. The diagnosis and fixes are identical in all three.

How to diagnose

The question to answer first is whether the chain is incomplete or the issuer is genuinely untrusted, because the fixes are different.

Test from a device that has never visited the site, ideally on a different network. If it fails there and works on your usual machine, the chain is incomplete and your browser had the intermediate cached.

Then check how many sites are affected. One site is a server configuration problem; many unrelated sites at once is interception on your device or network.

Why an incomplete chain is so hard to notice

This deserves its own explanation, because the invisibility is the reason the fault survives in production for months.

When a browser encounters an intermediate certificate it has not seen, it stores it. Every subsequent connection to any site using that intermediate then succeeds, whether or not that site sends it. So the person who installed the certificate, tested it immediately, and saw it work has proven only that their own browser had already collected the missing piece.

Whose browsers lack it varies: new devices, cleared profiles, less common browsers, and anything that does not fetch missing intermediates automatically. Some clients do go and fetch them; others refuse. Which means the affected share is not stable and not measurable from where you are standing.

Reports like "a few customers say the site is broken" and "our monitoring shows everything fine" are exactly what an incomplete chain looks like, and dismissing them as user error is the standard way this goes unfixed.

Non-browser clients deserve particular attention here. Command-line tools, mobile applications, payment callbacks, and server-to-server requests generally do not accumulate intermediates the way browsers do, so an incomplete chain that visitors barely notice can break integrations outright.

How to prevent it

Serve the full chain from the start, and verify it after every certificate change rather than after complaints. Renewal is the moment this breaks most often: a new certificate is installed correctly and its intermediate is forgotten, and the failure is invisible to whoever did the work because their browser still has the old intermediate cached.

Automating issuance and installation removes the step where this is forgotten, which is the practical reason it is worth doing beyond convenience.

Fix this with Bridge SSL

Bridge SSL issues certificates and serves the complete chain automatically, so the most common cause on this page cannot occur through oversight. Renewal installs the current chain along with the certificate rather than leaving it as a separate manual step. See what the platform offers at Bridge CDN.

FAQ

What does ERR_CERT_AUTHORITY_INVALID mean?

That the browser could not trace the certificate back to any authority in its trust store. The usual reason is an incomplete chain: the server sent its own certificate but not the intermediates that connect it to a root. Less often the certificate is self-signed or issued by an authority the device does not trust.

Why does the site work for some people and not others?

Because browsers keep intermediates they have seen before. A visitor whose browser already holds the missing link completes the chain from memory and notices nothing, while a first-time visitor on a clean device gets the warning. The split is not random: it tracks who has browsed where.

Can I fix it as a visitor?

Only when the cause sits on your side, which means a proxy or security product intercepting connections without its own authority installed on the device. An incomplete chain, a self-signed certificate, or an untrusted issuer all belong to the site, and nothing you change locally will resolve them safely.

Is it safe to continue anyway?

Not on a public site, and least of all on one where you sign in. The warning says the identity behind the connection could not be established, which is the exact condition an interceptor needs. Continuing turns a detected problem into an undetected one.

Why do I see it on every site suddenly?

Because something began intercepting all of your traffic: a corporate proxy whose authority was never installed on your device, or security software that started scanning HTTPS after an update. A fault at one site cannot produce warnings everywhere, so breadth is the diagnostic.

How do I check my chain is complete?

Test from a device that has never visited the site, ideally on another network, or use an external chain checker. Your own browser is the worst available witness, because it is the one most likely to be holding the intermediate whose absence you are trying to prove.

Certificates that renew themselves

Bridge SSL is the TLS layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included. Nothing to install, nothing to schedule.