net::err_cert_authority_invalid: What It Means and How to Fix It

• 27 June 2026
• by: Idris Mensah
• in: SSL Certificates
• Tags: cert authority invalid, certificate, ssl error
• note: no comments

You typed an address, hit enter, and instead of a website you got a red warning page and the string `net::err_cert_authority_invalid`. It looks alarming, but stay calm. This error is almost always a configuration detail, not a sign that the site is broken or dangerous. In most real cases the certificate itself is perfectly valid — the server just didn’t present it correctly.

Let me walk you through exactly what the browser is complaining about, why it happens, and how to fix it methodically, whether you own the site or you’re just trying to visit it.

Key Takeaways
• `net::err_cert_authority_invalid` means your browser could not confirm that the certificate was issued by a Certificate Authority (CA) it trusts — it couldn’t build a chain back to a trusted root.
• The single most common cause on a real, properly issued certificate is a missing intermediate certificate: the server sent only the leaf cert and skipped the intermediate(s) that link it to the trusted root.
• The confusing symptom is that the site can work in some browsers or devices and fail in others, making it look random when it isn’t.
• The fix is almost never “buy a new certificate.” It’s installing the full certificate chain (leaf plus intermediate bundle) your CA already gave you.
• Visitors seeing this error should first check whether it happens everywhere or only on their device, then check their clock, OS updates, and antivirus HTTPS scanning.

What does net::err_cert_authority_invalid actually mean?

When your browser connects to a site over HTTPS, the server hands it an SSL/TLS certificate. The browser then asks one question: was this certificate issued by an authority I trust?

To answer that, the browser tries to build a *chain of trust*. Every public certificate is signed by a CA, and that signature can be traced through a series of links back to a root certificate that lives in your operating system or browser’s trust store. If the browser can follow that path all the way to a root it already trusts, the padlock appears. If it can’t, you get `net::err_cert_authority_invalid` — literally, “I can’t verify the authority that issued this.”

The error is not saying the certificate is fake. It’s saying the browser cannot *prove* the certificate is legitimate because the trust path is broken or unknown.

How does certificate trust actually work?

Think of trust as a chain with three links:

1. Root certificate — the anchor. A small set of these ship pre-installed and pre-trusted in every browser and OS. Roots are kept offline and almost never touch your server directly.
2. Intermediate certificate(s) — the middle links. CAs sign your certificate with an intermediate, not the root, to keep the root protected. There can be one or more intermediates.
3. Leaf certificate — your site’s actual certificate, the one with your domain name on it.

For the browser to trust your site, two things must be true: it must already trust the root, and it must be able to see the complete chain from your leaf certificate up through the intermediates to that root. The browser already has the root. Your *server* is responsible for sending the leaf plus the intermediates. If the chain has a gap, the browser hits a dead end and throws the authority-invalid error.

This is also where most confusion starts. The certificate can be flawless and issued by a perfectly reputable CA, and you’ll still see this error if the intermediate is missing. The certificate isn’t wrong — it’s just incompletely installed. For a deeper look at how these links fit together, see .

What are the common causes of net::err_cert_authority_invalid?

There are a handful of root causes, and identifying which one you’re facing tells you exactly which fix to apply.

1. Missing intermediate certificate (the #1 cause). The server was configured with only the leaf certificate. Without the intermediate(s), the browser can’t connect your cert to a trusted root, so the chain breaks. This is overwhelmingly the most common reason a real certificate triggers this error.
2. Self-signed certificate. The certificate was signed by itself rather than by a recognized CA. There’s no real authority for the browser to trust, so it rightly refuses. Fine for local testing, never appropriate for a public site. See .
3. Untrusted or unknown CA. The certificate came from a CA that isn’t in the browser’s trust store — for example, an internal or private CA used inside a company.
4. Expired or outdated root store. On an old, un-updated device, the trusted root list may be stale. Newer roots the site relies on simply aren’t present yet.
5. Interception by antivirus, a proxy, or a corporate firewall. Some security software inspects HTTPS traffic by re-signing it with its own CA. If that CA isn’t trusted by your browser, every site looks authority-invalid.
6. The wrong certificate installed. A mismatched or leftover certificate from another domain or a previous setup was deployed, breaking the expected chain.

Is it just you, or is the site broken for everyone?

Before you change anything, run one quick test — it saves enormous time.

Try the same site from a different device on a different network. Use your phone on mobile data, or another computer entirely.

• If the error appears everywhere, the problem is server-side. The certificate chain is likely incomplete or misconfigured, and the site owner needs to fix it.
• If only your device fails, suspect something local: outdated antivirus doing HTTPS scanning, a corporate proxy, an old operating system with a stale root store, or a wrong system clock.

This single test cleanly separates an owner-side problem from a visitor-side one, and the two have completely different fixes.

Cause-to-fix reference table

Cause	Who fixes it	The fix
Missing intermediate certificate	Site owner	Install the complete chain (leaf + intermediate bundle) from your CA
Self-signed certificate on a public site	Site owner	Replace with a certificate from a trusted CA (free Let’s Encrypt / AutoSSL works)
Untrusted / private CA	Visitor or admin	Install the org’s root cert on managed devices, or use a public CA
Outdated root store / old OS	Visitor	Update the operating system and browser
Antivirus / proxy / firewall interception	Visitor	Disable HTTPS scanning or trust the corporate CA properly
Wrong certificate installed	Site owner	Re-install the correct certificate and matching chain

How do you fix net::err_cert_authority_invalid if you own the site?

If your test showed the error appears for everyone, the problem is on your server. Work through these in order.

1. Install the complete certificate chain. This is the main fix and resolves the large majority of cases. When your CA issued the certificate, it also provided an intermediate (or “CA bundle” / “chain”) file. Configure your server to present the leaf certificate plus that intermediate bundle, not just the leaf alone. The exact step depends on your server, but the principle is universal: the chain must be complete. For a walkthrough of the broader process, see .
2. Verify the chain with an SSL checker. Run your domain through any reputable SSL chain checker. It will explicitly tell you whether the chain is complete or where it breaks. This confirms the fix before your visitors test it for you — and it usually shows the certificate itself was fine all along.
3. Reissue from a trusted CA if needed. If the checker reveals the certificate truly came from an untrusted or private CA, reissue it from a recognized public CA. You rarely need to do this; most of the time the existing certificate is valid and just needs its chain completed.
4. Don’t use self-signed certificates on public sites. If you put a self-signed cert on a live, public-facing site, every visitor will see this error. Use a free, automatically trusted option such as Let’s Encrypt or an AutoSSL system instead. Self-signed certs belong on internal or development environments only.
5. Confirm you installed the right certificate. Double-check that the certificate matches the domain and that you didn’t leave a stale cert from a previous setup in place.

The recurring theme: the answer is almost never “buy a new certificate.” It’s “install the full chain you already have.”

How do you fix net::err_cert_authority_invalid as a visitor?

If your test showed only your device is affected, the fix is on your end.

1. Update your operating system and browser. This refreshes your trusted root store and often resolves errors on older devices immediately.
2. Check your system date and time. A clock set wildly wrong can break certificate validation. Set it to update automatically.
3. Pause antivirus HTTPS / SSL scanning. If your security software inspects HTTPS, temporarily disable that feature and retry. If the error vanishes, the software’s interception CA was the cause — re-enable it only once it’s configured properly.
4. On a corporate network, talk to IT. A proxy or firewall may be inserting a CA your browser doesn’t trust. IT can install that CA correctly on managed machines.
5. Don’t blindly bypass the warning on sites you don’t control. Clicking through is risky when you can’t verify why trust failed. Bypassing is only reasonable on something you own and understand, like your own test server.

For a wider look at the family of certificate problems and how they relate, see .

---

A note from DarazHost. Because the missing-intermediate problem causes so many of these errors, it’s worth removing the chance entirely. DarazHost’s free AutoSSL installs the complete certificate chain — leaf plus intermediates — automatically, and keeps it renewed for you. That means correctly-chained HTTPS out of the box, with no manual bundle wrangling and nothing for a browser to choke on. If any certificate question ever comes up, our support team is available 24/7 to help you sort it out.

---

Why does the site work in one browser but fail in another?

This is the detail that makes `net::err_cert_authority_invalid` feel random, and it’s worth understanding. When the intermediate certificate is missing from the server, some browsers and devices quietly compensate — they may have cached that intermediate from a previous visit to another site, or they fetch it on the fly. Others don’t, and they fail.

So the same site loads fine on your laptop’s main browser, fails on a fresh phone, and works again on a colleague’s machine. It looks inconsistent, but it isn’t. The server is sending an incomplete chain every time; you’re just watching different clients handle that gap differently. Run an SSL chain checker and the gap appears instantly. Fix the chain once, and every client succeeds.

This connects back to the foundation of how HTTPS trust is built — root, intermediate, and leaf working as one chain. For the full picture of how encryption and trust fit together, read our pillar guide: SSL Certificates: The Complete Guide to How HTTPS, Encryption, and Trust Work.

Frequently asked questions

Does net::err_cert_authority_invalid mean my certificate is invalid? Usually not. It means the browser couldn’t verify the *authority* that issued the certificate, most often because the intermediate certificate is missing from the server. The certificate itself is typically valid and just needs its full chain installed.

Why do I see this error on only one device? That points to a local cause: an outdated operating system with a stale root store, a wrong system clock, or antivirus/proxy software intercepting HTTPS with its own untrusted CA. Test the site on another device and network to confirm.

Will buying a new certificate fix it? Rarely. If the cause is a missing intermediate — which it usually is — a new certificate will have the exact same problem until you install the complete chain. Verify with an SSL chain checker before spending anything.

Is it safe to click through the warning? Only on a site you own and understand, such as your own test server. On sites you don’t control, bypassing the warning is risky because you can’t confirm why trust failed.

Can I use a free certificate to avoid this? Yes. Free, automatically trusted certificates from Let’s Encrypt or an AutoSSL system are issued by recognized CAs and, when installed with their full chain, won’t trigger this error. Self-signed certificates will.