NET::ERR_CERT_AUTHORITY_INVALID in Chrome and Brave: The Real Causes in 2026
The Chrome and Brave error NET::ERR_CERT_AUTHORITY_INVALID has two distinct causes that are easy to confuse: a certificate chaining to a legacy CA root that browsers have stopped trusting (a live, currently-enforced mechanism), or a CA force-revoking your certificate over its own internal compliance deadline. The dual serverAuth-plus-clientAuth EKU is often blamed, but Chrome does not reject those certificates until March 15, 2027 - the revocations happening now come from individual CAs' own CP/CPS deadlines, not browser enforcement.
Organizations keep hitting the same error in Chrome and Brave: NET::ERR_CERT_AUTHORITY_INVALID. The certificate was valid yesterday. Today, the browser refuses to trust it. Customer tickets pile up. There are two distinct causes, and they're easy to conflate - one is a live browser trust decision happening right now, the other is a CA-side compliance failure that can force a surprise revocation regardless of what Chrome itself enforces.
This guide walks through both causes, how to check your own certificate in 60 seconds, and what to actually ask your CA for in each case.
Cause 1: Certificate chains to a distrusted legacy root
Chrome (and Mozilla) periodically stop trusting older CA roots as part of root lifecycle policy, which generally limits how long a publicly-trusted TLS root stays in the trust store. When a root's constraint date passes, certificates that chain to it - even certificates that are otherwise perfectly valid - stop being trusted. This is a real, live, currently-enforced mechanism, and it's the more common cause of this error today.
Notable recent constraint events:
- SSL.com 2016 roots (constraint date June 15, 2026): SSL.com Root Certification Authority RSA, SSL.com Root Certification Authority ECC, SSL.com EV Root Certification Authority RSA R2, SSL.com EV Root Certification Authority ECC.
- DigiCert G1 roots (distrusted April 15, 2026): DigiCert Assured ID Root CA, DigiCert Global Root CA, DigiCert High Assurance EV Root CA.
- Entrust roots (constraint dates starting October-November 2024 across Chrome and Mozilla).
- Older constraint events at other CAs as roots age out under Chrome and Mozilla root lifecycle policies.
The fix is the same regardless of which CA you use: ensure the reissued certificate chains under your provider's current root hierarchy, not the legacy one. The current hierarchies at major commercial CAs (generally post-2020 roots) meet Chrome Root Program requirements and are not affected by these constraints. A non-exhaustive map of "current" hierarchies you can ask your CA to issue from:
- DigiCert: Global Root G2 / Global Root G3 (not affected).
- Sectigo: USERTrust roots and Sectigo Public Server Authentication Root R46 (current).
- SSL.com: TLS RSA Root CA 2022 and TLS ECC Root CA 2022.
- GlobalSign: R6 root family (current).
- GoDaddy: Go Daddy Root Certificate Authority G2 (current).
- Google Trust Services: GTS Root R1 through R4 (current).
- Microsoft Trusted Root Program operates a managed trust store rather than issuing public TLS certificates directly; certificates issued by CAs participating in the program follow the same Chrome rules above.
At least one CA's issuance system has been observed issuing certificates from the legacy hierarchy even when newer roots are available, sometimes producing two certificates simultaneously (one from each hierarchy) for the same order. This isn't unique to any one provider; it's a renewal-pipeline pattern to watch for across all CAs that maintain dual hierarchies during a root migration. If you reissued recently and are still seeing the error, verify which hierarchy the new certificate was actually issued from before deploying it.
Cause 2: Your CA revoked your certificate over its own compliance deadline
Here's the one worth getting precisely right, because a lot of secondhand advice on this gets it wrong. Chrome Root Program Policy does require public TLS certificates to eventually drop the clientAuth Extended Key Usage and be dedicated solely to server authentication - certificates that mix serverAuth and clientAuth were the norm for years and are being phased out. But the current policy (v1.8) sets that deadline at March 15, 2027, not June 15, 2026. The earlier date was in an older version of the policy (v1.6) and Chrome extended it before it took effect. As of today, Chrome does not reject a live TLS connection purely because the certificate has both EKUs.
So why do dual-EKU certificates keep getting force-revoked in 2026? Because individual CAs set their own internal deadlines in their Certification Practice Statement (CP/CPS) - often matching whatever the Chrome policy said at the time they wrote it - and those internal deadlines don't automatically update when Chrome's policy changes. If a CA's CP/CPS still says "no clientAuth after June 15, 2026" and their issuance system keeps including it past that date, they are non-compliant with their own published policy, independent of what Chrome currently enforces. Once that's discovered (by an auditor, a researcher, or Chrome's own compliance monitoring), the CA is contractually obligated to revoke every affected certificate, typically within days.
This isn't hypothetical. HARICA, a mid-sized public CA, hit exactly this failure twice in July 2026. Their CP/CPS retained the original June 15, 2026 clientAuth cutoff after Chrome extended the industry deadline to March 2027; their issuance system wasn't updated to match. Between June 15 and July 15, they issued 66,105 server TLS certificates that included the clientAuth EKU in violation of their own policy. When the mismatch was flagged, HARICA had to revoke every affected certificate still in service - 63,525 of them - by July 20, 2026. A second, unrelated CP/CPS violation (certificates issued without the required AIA OCSP URI) forced a further round of revocations by July 25.
The distinction matters operationally. If you're worried about "will Chrome reject my dual-EKU certificate," the honest answer is: not yet, and not until March 2027 at the earliest. If you're worried about "can my CA force-revoke my certificate on short notice for a compliance reason that has nothing to do with anything I did," the honest answer is yes, and it just happened to tens of thousands of HARICA customers with essentially no warning.
Check your own certificate in 60 seconds
Two openssl commands tell you which cause you're looking at, and whether you're exposed to a future forced revocation. Replace example.com with the affected hostname.
Check which root the certificate chains to (the live, current cause of AUTHORITY_INVALID):
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null \
| grep -E "(s:|i:)"
The output lists each certificate in the chain with its subject (s:) and issuer (i:). The topmost certificate's issuer names the root. If that name matches one of the distrusted 2016 SSL.com roots above (or another CA's distrusted root), that's your problem and the fix is a straightforward reissue.
Check the EKUs on the leaf certificate (not currently rejected by Chrome, but worth knowing before your CA's own deadline catches up with you):
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -ext extendedKeyUsage
If the output contains both TLS Web Server Authentication and TLS Web Client Authentication, your certificate isn't currently rejected by any browser for that reason alone - but if your CA has an internal CP/CPS deadline requiring serverAuth-only issuance (increasingly common as CAs align early with the eventual March 2027 Chrome deadline), you're a candidate for the kind of surprise mass revocation HARICA's customers experienced. Ask your CA directly whether their CP/CPS currently prohibits the clientAuth EKU on server certificates, and if so, get reissued proactively rather than waiting for them to revoke it for you.
What to ask your CA for
For a legacy-root chain problem, be specific about the hierarchy:
Please reissue this certificate from your current TLS root hierarchy (post-2020 root), not a legacy root scheduled for distrust. Confirm the new certificate chains to [current root name] before I deploy it.
For a dual-EKU certificate you want to get ahead of:
Please rekey/reissue this certificate with the serverAuth EKU only, dropping clientAuth. I want to confirm my certificates already comply with your CP/CPS requirements rather than wait for a compliance-driven revocation notice.
If the CA portal lets you select an issuance profile, choose the server-authentication-only profile (sometimes labeled "Web Server" or "TLS Server"). After receiving the reissued certificate, run the diagnostic commands above before deploying - verify the new certificate chains to the current root and carries only the EKUs you expect.
What if you actually need client authentication?
Some legitimate use cases require client authentication certificates - mutual TLS to a partner API (banking integrations, payment processor APIs, B2B booking platforms) is the most common. The Chrome policy doesn't ban client authentication certificates. It separates them from server certificates, on a timeline that's still a year-plus out - but most CAs are already steering new issuance toward serverAuth-only server certs, so this is worth planning for now rather than waiting for a deadline.
If you need a client authentication certificate, you want a dedicated client-authentication-only certificate (clientAuth EKU, no serverAuth) issued from a Mozilla-trusted client root. This is a distinct certificate product from a TLS server certificate. CAs that offer Mozilla-trusted client roots (look for "Client Authentication" or "mTLS" certificate products) can issue these. Don't try to dual-purpose a single certificate; the public-CA ecosystem has explicitly moved away from that pattern.
For internal mTLS between your own services, a private CA is the right tool: kubernetes service mesh CAs, HashiCorp Vault, AWS Private CA, smallstep, or your own internal PKI. Public TLS certificates were never the right answer for service-to-service authentication at scale.
For requesters who want a dual-EKU certificate anyway
Some customers still request dual-EKU certificates for legacy banking, mainframe file transfer, or specific partner integrations that documented a dual-EKU requirement years ago. The honest answer: no public CA will issue one for use in browser-facing TLS. The Chrome Root Program prohibits it; CAs that issue against the policy risk distrust events of their own. If the receiving partner truly requires it, your options are: a private CA certificate (works if the partner trusts your private CA), two separate certificates (one for server auth, one for client auth, both deployed where each is needed), or pushing back on the partner to update their integration requirements.
This is the shifting PKI baseline in practice
Root distrust events aren't a one-off. Chrome's Root Program continues to tighten requirements: certificate validity is shortening (200 days as of March 2026, dropping to 100 in March 2027 and 47 in March 2029), the clientAuth EKU deadline lands in March 2027, and root distrust events for older roots will continue under root lifecycle policy. Layered on top of the browser's own timeline is the CA-compliance risk HARICA's incidents illustrate: individual CAs can force revocations well ahead of any industry-wide deadline, on their own schedule, for reasons entirely internal to their own policy management.
The teams that handle these events cleanly are the ones that read the Chrome and Mozilla CA program announcements ahead of time, inventory their own certificates against the upcoming changes, and watch for CA-side compliance notices independently of browser-enforced deadlines. The teams that don't, find out when customers tell them - or when their CA emails them a five-day revocation notice.
Get ahead of the next ecosystem change
TLS Radar inventories every certificate across your domains, flags certs whose EKUs include something a browser will eventually reject, identifies certs chaining through a root scheduled for distrust, and alerts you to configuration drift before it surfaces as a customer ticket. Built to scale from a handful of sites to enterprise portfolios, with API integration, SAML/SSO, and pricing tailored to your certificate volume.
Related reading
Frequently asked questions
- Why does Chrome say NET::ERR_CERT_AUTHORITY_INVALID when my certificate is valid?
- Two causes. Most often, your certificate chains to an older CA root that Chrome has stopped trusting under root lifecycle policy - a live, currently-enforced mechanism. Less obviously, your CA may have revoked the certificate over its own internal compliance deadline. The certificate can be technically valid in both cases; what changed is on the browser or CA side, not yours.
- Does Chrome reject certificates with both serverAuth and clientAuth EKUs?
- Not yet. Chrome Root Program Policy v1.8 requires publicly trusted TLS certificates to drop the clientAuth EKU for certificates issued on or after March 15, 2027. As of today, Chrome does not reject a live connection purely because a certificate carries both EKUs. An earlier June 15, 2026 date appeared in policy v1.6 but was extended before it ever took effect.
- Why are dual-EKU certificates being revoked in 2026 then?
- Because individual CAs set their own clientAuth deadlines in their CP/CPS, often matching whatever Chrome's policy said when they wrote it. When Chrome extended its deadline to March 2027 but a CA's CP/CPS and issuance system did not update in step, the CA became non-compliant with its own policy and had to revoke. That is what happened to HARICA - a self-inflicted policy failure, not browser enforcement.
- How do I check which cause is affecting my certificate?
- Run two openssl commands. Use 'openssl s_client -showcerts' and read the issuer lines to see which root your chain terminates at (checks the distrust cause). Run 'openssl x509 -ext extendedKeyUsage' on the leaf certificate to see whether it carries both TLS Web Server Authentication and TLS Web Client Authentication (checks your exposure to a CA's clientAuth deadline).
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.