TLS Client Authentication Migration: A Practical Playbook
Chrome's dual-use ban takes effect June 15, 2026. This guide covers who's affected, the public-CA removal timeline, and the step-by-step path to migrate your mTLS infrastructure before the deadline.
April 13, 2026 · [cyphrs] Team · 11 min read
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. This guide covers exactly what's happening, who's affected, and the six-step playbook to get migrated safely.
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.
| Certificate Authority | ClientAuth Removed By Default | Full Removal | Status |
|---|---|---|---|
| Let's Encrypt | February 11, 2026 | May 13, 2026 | Already removed by default |
| Sectigo | September 15, 2025 | February 2027 | Removed by default |
| DigiCert | October 1, 2025 | May 1, 2026 | Removed by default |
| SwissSign | Q1 2026 | June 2026 | In progress |
| All other public CAs | Varies | June 15, 2026 | Must comply by deadline |
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:
mTLS Between Microservices
Using the same Let's Encrypt or public CA cert for both serving HTTPS and authenticating service-to-service calls. This is the most common pattern and the one that will break first.
VPN Client Certificates
Any VPN setup that uses public CA certificates for client authentication. This includes some OpenVPN and WireGuard deployments that share server certs for both sides.
API Gateway Authentication
API gateways or load balancers that use public certificates to authenticate upstream clients. Common in CI/CD pipelines and partner integrations.
Wi-Fi / 802.1X Onboarding
Enterprise Wi-Fi that uses public TLS certificates for EAP-TLS device authentication. The clientAuth EKU is required for the handshake to complete.
Not affected: Standard HTTPS websites that only use certificates for server authentication. If your cert's sole job is serving web traffic, this change doesn't touch you. Also not affected: private CA certificates – these operate outside the Chrome Root Program and can include whatever EKUs your organisation needs.
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:
- 1.ACME client triggers scheduled renewal
- 2.New certificate issues cleanly – no errors, no warnings
- 3.Certificate is valid, chain is correct, expiry looks fine
- 4.Server TLS continues working – HTTPS is unaffected
- 5.mTLS connections start dropping – clientAuth EKU is missing
- 6.Downstream services can't authenticate – cascading failures
- 7.Team spends hours debugging a "TLS handshake error" before checking EKU fields
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. Audit First: The 60-Day Checklist
Before choosing a migration path, you need visibility into where dual-EKU certificates are actually in use. This is the first half of the playbook – audit what you have before you change what you have.
Inventory every certificate with the clientAuth EKU
Scan every endpoint, load balancer, API gateway, and service mesh. Flag any certificate that contains 1.3.6.1.5.5.7.3.2 (the clientAuth OID). Scout can do this across your entire estate in minutes.
Classify public vs private and map against CA removal timelines
For each clientAuth certificate, determine whether it was issued by a public CA (affected) or a private CA (not affected). Cross-reference the table in Section 3. If a Let's Encrypt cert renews after May 13, it's already affected. DigiCert after May 1. Know which certs will lose clientAuth on their next renewal.
Identify mTLS dependencies and the blast radius
For each affected certificate, document which services depend on it for client authentication. These are the connections that will break on renewal. Record both sides of every mTLS relationship – a microservice mesh has N2 trust edges.
7. Choose a Migration Path
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.
What this looks like:
- – Server cert: public CA (Let's Encrypt, DigiCert, etc.) with serverAuth EKU only
- – Client cert: private CA with clientAuth EKU
- – Services present the right certificate for each role
- – Trust stores updated to trust your private CA root for client verification
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.
What you gain:
- – Unified trust model: one CA for both server and client certs internally
- – No dependency on external CA policy changes (this won't be the last one)
- – Freedom to set your own lifetimes, rotation policies, and EKU combinations
- – Foundation for mTLS as an identity layer, not just an encryption layer
- – Immune to 47-day certificate compression for internal services
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.
Full execution walkthrough: Path B is the focus of our Migrating from Public to Private CA playbook – a dedicated six-step guide covering inventory, architecture choice, trust-anchor distribution, enrollment protocol selection, cutover, and revocation across mTLS, VPN, RADIUS/802.1X, and device authentication use cases.
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.
8. Execute the Migration
Once you've chosen a path, execution splits into two final steps – issuing new certificates through private trust, then cutting over services with monitoring that will catch future silent-drop events.
Stand up private trust and issue replacement certificates
Deploy your private CA (or use an existing one), distribute the trust anchor to every relying party via Group Policy, MDM profiles, config management, or manual upload. Issue replacement certificates with the right EKU for each role – clientAuth only for authentication flows, serverAuth only for HTTPS. Keep certificate profiles tight.
Cut over services and add EKU monitoring
Update trusted-issuer lists on RADIUS servers, VPN concentrators, mTLS ingress, and API gateways to accept both old and new chains simultaneously. Roll clients over the natural renewal cycle. Update certificate monitoring to check EKU fields – not just expiry – so future silent-drop events are caught before your services are.
For the full Path B execution – every trust-anchor distribution channel, enrollment-protocol decision, and revocation check – the Migrating from Public to Private CA guide walks the detailed six-step playbook across all four affected use cases.
9. 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:
47-Day Certificates
SC-081 compresses certificate lifetimes from 398 to 47 days by 2029. Phase one (200 days) is already live.
Read more →ClientAuth EKU Ban
Chrome separates server and client trust hierarchies. Public CAs exit client authentication permanently. June 15, 2026.
You are herePost-Quantum Transition
Google won't put PQC signatures into X.509. Merkle Tree Certificates are coming. A new format for the public web.
Read more →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.
10. Frequently Asked Questions
What is the difference between a public and a private CA?
A public CA (Let's Encrypt, DigiCert, Sectigo) is trusted by browsers and operating systems by default – that's what lets any device connect to a public website without a trust warning. A private CA is an internal authority you operate or control. Its root is only trusted inside your own systems, and you set your own lifetimes, EKUs, and issuance policies.
How do I generate a private CA?
You can stand up a private CA with open-source tooling like OpenSSL, smallstep CLI, or Hashicorp Vault PKI for small deployments, or use a managed option like AWS Private CA or [cyphrs] Trust CA. The core steps are identical: generate a root key pair, self-sign the root certificate, issue one or more intermediates, and distribute the root to every relying party's trust store.
Is mTLS being deprecated?
No. mTLS is not being deprecated – only the ability to use public CA certificates for the client side of mTLS. Chrome's June 15, 2026 change removes clientAuth from public hierarchies, but mTLS itself remains the recommended protocol for service-to-service authentication and is expanding in zero-trust and agent-to-agent architectures.
Why is the root certificate not trusted after migration?
If a client shows "root certificate not trusted" after migrating to private trust, the private CA root hasn't been distributed to that endpoint's trust store. Unlike public CA roots, private roots are not pre-installed. Deploy the root via Group Policy on Windows, MDM profiles on Apple and Android devices, config management (Ansible, Puppet, Chef), or container base images.
Should I still trust DigiCert certificates after this change?
Yes. DigiCert remains a trusted public CA under Chrome Root Program v1.6. What's changing is the shape of their issuance: certificates from DigiCert's public hierarchy will be serverAuth-only after May 1, 2026. Their separate X9 PKI is outside Chrome's trust store and continues to support clientAuth for partners needing publicly rooted mTLS across organisational boundaries.
How is mTLS different from TLS?
Standard TLS authenticates only the server – the client verifies the server's certificate, but the server has no cryptographic proof of who the client is. Mutual TLS (mTLS) adds the reverse: the client also presents a certificate that the server validates. Both sides prove identity, which is why mTLS is the default authentication primitive in modern service-to-service and zero-trust architectures.
11. Start Here
The June 15 deadline is fixed. But the migration doesn't have to be a fire drill.
Scan with Scout
Find every certificate with clientAuth EKU across your infrastructure. Know the blast radius before you start migrating.
Stand Up Trust CA
Deploy a private CA with full server and client authentication support. Your trust, your policies, your timelines.
Manage in Hub
Track your migration progress. Monitor public and private certificates from a single pane with EKU-level visibility.
Free assessment: Not sure how exposed you are? Run a Scout scan against your domains – it checks EKU fields as part of the certificate analysis and flags any dual-EKU public certificates that will be affected. Takes under a minute.