Since June 15, 2026, organizations have been seeing 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. The technical explanation is buried in the Chrome Root Program Policy v1.8.
There are two distinct changes that took effect on that date, and most cases trace to one of them (sometimes both). If your certificate is throwing this error in Chrome 149+, Brave, or Opera, this guide walks through the two causes, how to check your own certificate in 60 seconds, and the exact wording to use when asking your CA to fix it.
Cause 1: Certificate with both serverAuth and clientAuth EKUs
Chrome Root Program Policy v1.6 (carried forward through v1.8) requires public TLS certificates to be dedicated solely to server authentication. The clientAuth Extended Key Usage (EKU) - which used to be allowed on "dual-purpose" certificates that handled both server TLS and client TLS / mTLS authentication - was deprecated in October 2022 with a multi-year sunset. As of June 15, 2026, any newly-issued public certificate that includes both the serverAuth EKU and the clientAuth EKU is rejected by Chrome regardless of how valid the rest of the certificate is.
Symptom: Chrome 149+, Brave, and Opera throw NET::ERR_CERT_AUTHORITY_INVALID. The certificate looks fine to Safari (different trust store and policy). Edge - which also follows Chrome's root store but on a slightly delayed rollout in some configurations - may or may not show the same error depending on the version your visitor is running. Firefox, with its own Mozilla-managed trust store, is generally unaffected by this specific change.
Some CAs still have legacy certificate issuance profiles that include both EKUs. If your renewal pipeline calls the CA's default profile, and that profile hasn't been updated, you can receive a brand-new certificate this week that Chrome will reject. The certificate itself is signed correctly and chains to a trusted root; the rejection is solely about the EKU combination.
Cause 2: Certificate chains to a distrusted legacy root
Chrome's June 15, 2026 changes also include constraint dates on multiple legacy CA roots. The pattern is industry-wide: CAs operating roots created in the 2014-2016 era are migrating customers onto newer hierarchies that meet current Chrome Root Program requirements. Certificates that chain to a legacy root and were issued (notBefore) on or after the constraint date are no longer trusted in Chrome.
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, which generally limit publicly-trusted TLS roots to ~15 years from key generation.
This is independent of the EKU question. A certificate with serverAuth only, issued from any of these legacy roots after its constraint date, will also fail in Chrome. 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.
Check your own certificate in 60 seconds
Two openssl commands tell you which (if either) cause is hitting you. Replace example.com with the affected hostname.
Check the EKUs on the leaf certificate:
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, you're hitting cause 1. The certificate has both EKUs and Chrome rejects it.
Check which root the certificate chains to:
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), you're hitting cause 2.
What to ask your CA for
When requesting reissuance, be specific. The phrasing that has worked for customers in this exact situation:
Please rekey/reissue this certificate WITHOUT the clientAuth EKU, per Chrome Root Program Policy v1.8 (Chrome 149+ rejects certificates with both serverAuth and clientAuth EKUs as of June 15, 2026). Issue from your current TLS root hierarchy (post-2020 root), not legacy 2016 roots.
If the CA portal lets you select an issuance profile, choose the server-authentication-only profile (sometimes labeled "Web Server" or "TLS Server"). If it doesn't, escalate to support and reference the policy directly. After receiving the reissued certificate, run the diagnostic commands above before deploying - verify the new certificate has only the serverAuth EKU and chains to the current root, not the legacy one.
What if you actually need client authentication?
Some legitimate use cases require client authentication certificates - mutual TLS to a partner API (Hotelbeds, banking integrations, payment processor APIs) is the most common. The Chrome policy doesn't ban client authentication certificates. It separates them from server certificates.
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
The June 15 change isn't a one-off. Chrome's Root Program continues to tighten requirements: similar EKU-related changes are planned at later dates (the Chrome Root Program has signaled further restrictions in 2027 and beyond), certificate validity is shortening (200 days as of March 2026, dropping to 100 in March 2027 and 47 in March 2029), and root distrust events for older roots will continue under root lifecycle policy.
The teams that handle these events cleanly are the ones that read the Chrome and Mozilla CA program announcements ahead of time and inventory their own certificates against the upcoming changes. The teams that don't, find out when customers tell them.
Get ahead of the next ecosystem change
TLS Radar inventories every certificate across your domains, flags certs whose EKUs include something the 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
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.