TLS Client Authentication Ends June 2026: What to Do Before the Deadline

1. The Deadline Nobody Can Ignore

On June 15, 2026, Google Chrome will stop trusting any newly issued public TLS certificate that includes the Client Authentication Extended Key Usage (EKU). This isn't a recommendation. It's a hard policy change in the Chrome Root Program, and every public certificate authority on earth must comply.

The change means a structural split: public TLS certificates will be server-only. If you need a certificate for client authentication – for mTLS between services, VPN access, Wi-Fi onboarding, API-to-API calls, or any form of mutual TLS – you can no longer get it from a public CA. Not from Let's Encrypt. Not from DigiCert. Not from Sectigo. The capability is being permanently removed from the public trust ecosystem.

If your infrastructure relies on dual-purpose public certificates for mTLS, you have roughly 63 days to migrate. Here's exactly what's happening, who's affected, and what to do.

2. What's Actually Changing (And Why)

Every X.509 certificate contains Extended Key Usage fields that declare what the certificate is authorised to do. Historically, most public CAs issued certificates with both id-kp-serverAuth (server TLS) and id-kp-clientAuth (client authentication) included by default. These "dual-EKU" certificates let you use the same cert for both serving HTTPS and authenticating as a client in mTLS connections.

Chrome Root Program Policy v1.6 mandates that certificate hierarchies in Chrome's trust store must be dedicated solely to TLS server authentication. The logic is sound: the security properties, issuance requirements, and trust models for server authentication and client authentication are fundamentally different. Bundling them into one certificate creates a confused deputy problem – a certificate trusted for one purpose gets implicitly trusted for another.

Google's position is that server certificates should prove server identity, and client certificates should prove client identity, and these should come from separate trust hierarchies with separate governance. That's architecturally cleaner, and it aligns with where zero-trust frameworks have been heading for years. But it also breaks a lot of existing deployments.

3. The CA Timeline: Who's Dropping ClientAuth and When

Most CAs aren't waiting for June 15. They're removing the clientAuth EKU ahead of the deadline, which means you may already be affected depending on your CA and when your certificates were last renewed.

The critical detail: this change happens silently during certificate renewal. Your ACME client runs, the cert issues cleanly, it looks valid – but the clientAuth EKU is gone. If you have monitoring that checks certificate validity but doesn't check EKU fields, you won't catch it until mTLS connections start failing. We've covered the technical details of how and why this is happening.

4. Who's Affected

If you answer "yes" to any of these, you need to act before June 15:

5. The Silent Failure Risk

This change is particularly dangerous because of how it manifests. There's no big red banner. The certificate issues successfully. Standard validation passes. The failure only surfaces when something tries to use the certificate for client authentication – and then it fails with a generic TLS handshake error that could mean a dozen different things.

Here's the sequence that's already catching teams off guard:

The average time to identify and remediate certificate-related outages is over five hours. If your monitoring doesn't specifically check for EKU fields – and most certificate monitoring doesn't – you're flying blind.

6. The Migration: What to Do Before June 15

There are three viable paths forward. Which one you choose depends on your current architecture and how deeply mTLS is embedded in your infrastructure.

Path A: Split Your Certificates (Minimum Viable Fix)

Keep using public certificates for server authentication (HTTPS). Issue separate certificates from a private CA for client authentication. This is the smallest change that solves the immediate problem.

Effort: Medium. Requires standing up a private CA (or using an existing one like AD CS, AWS Private CA, or a purpose-built internal CA) and updating your service configurations to present separate certs per role.

Path B: Move Internal Services to Private Trust Entirely (Recommended)

This is the approach we recommend at [cyphrs]. Rather than splitting certificates across two trust hierarchies, ask the question: do your internal services need public certificates at all?

Services that only communicate with other services inside your infrastructure don't need to be trusted by Chrome, Firefox, or Safari. They need to be trusted by each other. A private CA gives you both server and client authentication from a single trust hierarchy that you control – with whatever certificate lifetimes, EKUs, and policies make sense for your architecture.

Effort: Higher upfront, but this is the last migration you'll need to do. Every future policy change from the CA/Browser Forum – shorter lifetimes, new EKU restrictions, DCV reuse limits – only affects your public-facing certificates, which are a fraction of your total estate.

Path C: DigiCert X9 PKI (Special Case)

DigiCert operates the X9 PKI root hierarchy separately from the Web PKI. Because it's not part of Chrome's root store, it can continue issuing dual-EKU certificates. This is a viable option if you need publicly rooted certificates with clientAuth for internet-facing mTLS (e.g., partner-to-partner API authentication across organisational boundaries). For internal mTLS, it's more expensive and less flexible than running your own private CA.

7. The 60-Day Audit Checklist

Before choosing a migration path, you need visibility into where dual-EKU certificates are actually in use. Here's the checklist:

8. The Bigger Picture: This Won't Be the Last Policy Change

The clientAuth EKU removal is one of three major public certificate changes converging in 2026:

Each of these changes shares the same underlying lesson: the public certificate ecosystem is getting more restrictive, more specialised, and more opinionated about what public certificates should and shouldn't do. Organisations that depend on public certificates for everything – server TLS, client auth, internal services, machine identity – are going to keep getting disrupted.

The organisations that won't have to scramble at every policy change are the ones that have already separated their public and private trust. Public certificates for public-facing endpoints. Private certificates – issued by infrastructure you control – for everything else.

9. Start Here

The June 15 deadline is fixed. But the migration doesn't have to be a fire drill.