clientAuth EKU Removal: Where mTLS Breaks and How to Migrate to Private PKI

Your mTLS mesh can pass every health check, renew every certificate on schedule, and still stop authenticating clients overnight. Nothing gets hacked. Nothing expires early. A certificate simply renews, quietly comes back missing one Extended Key Usage value, and the next handshake that depends on it fails. That is the shape of the clientAuth sunset, and it is already underway.

TL;DR Chrome Root Program Policy v1.8, Section 1.3.2, is removing the clientAuth Extended Key Usage (EKU) from publicly trusted TLS leaf certificates. New subordinate CAs have had to be serverAuth-only since June 15, 2026, and every new public leaf certificate must be serverAuth-only by March 15, 2027.Your certificate authority almost certainly cuts over before Chrome’s own deadline. DigiCert, Sectigo, Let’s Encrypt, Google Trust Services, and SSL.com have all set earlier internal cutoffs, some as early as September 2025.The failure is silent by design: existing certificates keep working until they expire, so the break shows up at the next routine renewal, not on any policy date, and it can surface hours or days later on unrelated infrastructure.Reissuing or pinning the leaf certificate will not save you. Verifiers compute the effective EKU as the intersection of every certificate in the chain, so once your issuing hierarchy goes serverAuth-only, the leaf’s clientAuth OID stops being honored even if it is still printed on the certificate.The durable fix is a private PKI you govern for client and machine identity, built in-house or consumed as PKI-as-a-Service, migrated through a four-phase, zero-downtime plan.

Key Takeaways

• Know the mandate: Chrome Root Program Policy v1.8 is the source. June 15, 2026 already put single-purpose sub-CA hierarchies in effect. March 15, 2027 is the leaf-certificate hard boundary. Your own CA likely cuts over earlier than either date.
• Inventory now, not at renewal time: Find every clientAuth consumer across mTLS, service mesh, IoT, VPN, 802.1X, SIP, and legacy machine-to-machine systems.
• Skip the dead ends: Opt-in flags, last-minute reissues, and non-browser roots only delay the cliff. A private PKI is the only option that gives you EKUs and issuance policy you actually control.
• Check the whole chain, not just the leaf: An intermediate losing clientAuth can break a leaf certificate before that leaf’s own renewal ever arrives.
• Search beyond your own certificate inventory: Certificate Transparency logs surface forgotten and shadow-IT certificates your own records miss.
• Migrate deliberately: Discover, design, deploy, then cut over with parallel trust, and validate the full chain in staging before a production renewal forces the issue for you.

What’s Actually Changing

For years, one publicly trusted TLS certificate could carry two Extended Key Usage values at once: id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) and id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2), as defined in RFC 5280 Section 4.2.1.12. A single certificate could terminate HTTPS as a server and also authenticate as a client in mTLS, service-to-service, and machine-identity flows.

Under Chrome Root Program Policy v1.8, Section 1.3.2, that dual role is going away. New publicly trusted TLS leaf certificates will carry serverAuth only. Existing dual-purpose certificates stay valid until they expire, but every renewal issued after your CA’s enforcement date comes back serverAuth-only by default.

Two dates matter at the policy level: new subordinate CAs disclosed to the CCADB have had to be serverAuth-only since June 15, 2026, and every subscriber (leaf) certificate issued on or after March 15, 2027 must assert serverAuth only. Google first put the split on the table at the CA/Browser Forum’s F2F-63 meeting in October 2024, then codified it as a Chrome Root Program policy rather than a CA/Browser Forum ballot. Chrome still represents roughly two-thirds of the global browser market, so a public CA that ignores Chrome’s root program risks losing trust for most of the web, and every major CA is treating the policy as mandatory.

This piece assumes you already know that much. For the full mandate history, the CA/Browser Forum’s role, and Chrome’s policy language section by section, see Encryption Consulting’s dedicated breakdowns of Chrome Root Program Policy v1.8 and the CA/Browser Forum mandate. What follows is the part most coverage of this change skips: exactly where your infrastructure breaks, how to find every certificate at risk, and how to move client identity somewhere durable before a renewal forces the issue in production.

Your CA’s cutoff, not Chrome’s, is your real deadline

Public certificate authorities are moving well ahead of Chrome’s own enforcement dates. Existing certificates keep working until they expire, but the first renewal after your CA’s cutoff comes back serverAuth-only, and that is the moment client authentication silently breaks.

Certificate Authority	clientAuth off by default	Hard cutoff (no clientAuth issued)
DigiCert	October 1, 2025	March 1, 2027 (all DigiCert brands)
Sectigo	October 7, 2025	February 10, 2027, no exceptions
Let’s Encrypt	February 11, 2026 (default ACME profile)	July 8, 2026 (tlsClient bridge profile retired)
Google Trust Services	November 10, 2025 (CSRs rejected)	April 13, 2026, no exceptions
SSL.com	September 15, 2025	Aligned to Chrome, March 15, 2027

Check your own CA’s advisory page directly; several of these dates have already moved earlier than originally announced once, and CAs are not shy about accelerating further.

Why the Split Is Actually the Correct Call

It is tempting to treat this as bureaucratic churn from a browser vendor. It isn’t, and it is worth understanding why before you architect around it, because the same logic should shape how you design the private PKI you migrate to.

Validation is not authorization: Public certificate issuance proves domain control, through methods like ACME HTTP-01 and DNS-01 as defined in RFC 8555 Sections 8.3 and 8.4, or organization identity for OV and EV certificates, per Baseline Requirements Section 3.2.2.4. None of that verifies that a given system is authorized to act as a client against your infrastructure. A public clientAuth certificate was always advertising a trust property the issuing CA never actually validated.

Dual EKU doubles the blast radius of one stolen key: A certificate carrying both serverAuth and clientAuth means one compromised private key lets an attacker impersonate your server and move laterally as a trusted client, using the same key for both. Separating certificates, keys, and lifecycles by purpose removes that second attack path entirely. It is least privilege applied to certificates, not a new idea, just finally enforced at the EKU level.

Where the mTLS Handshake Actually Breaks

This is the detail most explainers of this change skip, and it’s the one that matters most when you’re debugging a 2 a.m. page.

In a mutual TLS handshake, the server sends CertificateRequest, the client replies with its Certificate, and then sends CertificateVerify, a signature proving it holds the corresponding private key (this is the TLS 1.3 flow; TLS 1.2 adds an unencrypted ClientKeyExchange step in between, but the failure point is identical). The verifier does two genuinely separate checks here, and conflating them is where most postmortems go wrong.

First, it runs path validation as defined in RFC 5280 Section 6, building and checking the chain to a trusted root. This step passes. The certificate chain is completely valid. RFC 5280 defines the EKU extension itself in Section 4.2.1.12, but it does not require a verifier to check EKU purpose as part of path validation.

That purpose check is added on top by the specific TLS implementation, not mandated by the RFC. Major libraries, including OpenSSL, Java’s JSSE, Go’s crypto/tls, and Rust’s rustls, all enforce EKU-purpose validation by default: they look for clientAuth in the presented certificate, don’t find it, and reject the certificate outright. This is a hard authentication failure, not a warning, and it typically happens as soon as the verifier evaluates the client certificate’s EKU, often right at the Certificate message rather than only after CertificateVerify. No application data flows before this check runs.

The enforcement is deliberate, not incidental. Go’s own issue tracker documents a case (golang/go#23884) where a serverAuth-only client certificate was correctly rejected under RequireAndVerifyClientCert on Go 1.9.4, then wrongly accepted after a Go 1.10 regression. Go’s maintainers treated the regression as a bug and fixed it, which is about as clear a confirmation as you get that EKU enforcement is the intended default behavior across the ecosystem, not an edge case you can rely on being ignored.

The Chaining Trap: Reissuing the Leaf Won’t Save You

Here’s the detail that catches teams who think they’ve bought themselves time. Verifiers such as Chrome and the underlying TLS stacks don’t just check the leaf certificate’s EKU. They validate the entire chain, and the effective EKU of a certificate is the intersection of the purposes permitted by every certificate in the path above it.

Consider a leaf certificate that still lists both serverAuth and clientAuth, issued under an intermediate CA that has migrated to a serverAuth-only hierarchy:

{ serverAuth }  ∩  { serverAuth, clientAuth }  =  { serverAuth }

The leaf’s clientAuth OID is still printed on the certificate. It is simply ignored, because no certificate above the leaf may carry an EKU that excludes clientAuth for that purpose to survive down the chain. Silence works: an intermediate CA certificate with no EKU extension at all is unrestricted. It is an explicit EKU that omits clientAuth that breaks everything beneath it.

The practical consequence: you cannot keep clientAuth alive by reissuing or pinning your existing leaf certificate once your issuing CA’s hierarchy moves to serverAuth-only. An intermediate can lose clientAuth capability for everything under it before any individual leaf certificate’s own renewal date arrives. If you’re only tracking leaf certificate expiry dates, you’re tracking the wrong clock.

Which Workloads Silently Break

The blast radius is wider than most certificate inventories assume, and enforcement varies by vendor, which is exactly what makes this hard to scope from a spreadsheet alone.

Workload	Why it depends on clientAuth	Enforcement notes
mTLS / service mesh	Sidecars authenticate to each other with client certificates for east-west traffic	Usually strict; where outages are most visible
Partner & B2B APIs	Gateways present client certificates to prove identity in cross-organization mTLS	Contractually strict in most integrations
IoT & device identity	Each device presents a client certificate to prove which fleet member it is	Strict; device fleets are hard to patch quickly
VPN client authentication	Clients authenticate to the gateway with a certificate (OpenVPN, AnyConnect, Fortinet)	Vendor-dependent, generally strict
Wi-Fi / 802.1X (EAP-TLS)	The supplicant (device) certificate typically carries clientAuth	RFC 5216 §5.3 recommends the check but also accepts no EKU at all
SIP / SBC / unified comms	Some carriers require clientAuth for Session Border Controller trust	Carrier-dependent; Microsoft Teams Direct Routing docs currently accept SBC certs without clientAuth
Load balancers	Check client certificates, but only enforce clientAuth if explicitly configured	F5 BIG-IP enforces EKU purpose only if an admin turns that rule on
Legacy machine-to-machine middleware	Older systems expect one dual-purpose certificate for both roles	Often hardest to patch; frequently unowned by any current team

The honest takeaway here is that enforcement is genuinely vendor-dependent. Verify your own stack rather than assuming every workload in this table breaks on the same day; some of it may keep limping along on a technicality until a future update closes that gap too.

The Silent Failure Pattern

The most dangerous property of this change is that nothing announces it. The failure sequence looks like this:

1. Policy day arrives: Nothing happens. Existing dual-EKU certificates remain valid until they individually expire.
2. Weeks pass: Deployments look completely stable. Automated ACME renewals keep running exactly as they always have.
3. A routine renewal fires: The certificate renews successfully, but it comes back serverAuth-only. It is a perfectly valid certificate. It is just missing the one capability that mattered for this workload.
4. The next mTLS handshake fails: The EKU check rejects the certificate the next time it’s used for client authentication, which can be hours or days after the renewal, on infrastructure that looks completely unrelated to whoever renewed the certificate.

Because rotation is automated end to end, one renewal cycle on one certificate authority can take down an entire service mesh, and it’s genuinely hard to diagnose, because the certificate passes every check except the one that actually matters. Chain validation succeeds. Expiry is fine. The signature is valid. It’s serverAuth-only, and nobody was watching for that specific field.

How to Find Your clientAuth Exposure

You cannot migrate what you haven’t found. Six ways to build a real inventory, roughly in order of effort:

1. Inventory by EKU: Enumerate every publicly issued TLS certificate you hold and flag anything carrying clientAuth. A cryptographic bill of materials (CBOM) workflow scales this across a large estate.
2. Search Certificate Transparency logs: Chrome’s policy requires CT logging for all publicly trusted TLS certificates, so an aggregator like crt.sh will return the full issuance history for your domains, including forgotten or shadow-IT certificates nobody remembers requesting.
3. Check the full chain, not just the leaf: Verify what your issuing CA’s intermediates actually assert. The capability can die at the intermediate before the leaf’s own renewal.
4. Map the dependency graph: Identify which mutual-auth flows in your environment actually consume clientAuth, not just which certificates carry the EKU.
5. Confirm dual-certificate support per application: Can each application hold separate client and server certificates, or does it assume one certificate does both? If it can’t, that’s a vendor conversation to start now, not in March 2027.
6. Automate discovery with a CLM platform: Manual checks don’t scale past a handful of certificates. A certificate lifecycle management platform inventories EKUs continuously, not just when someone remembers to audit.

Three commands cover most quick checks, all portable across Windows, Linux, and macOS:

# Read the EKU extension from a certificate file on disk openssl x509 -in cert.pem -noout -ext extendedKeyUsage   # Check the EKU on a certificate presented by a live TLS endpoint echo | openssl s_client -connect <hostname>:443 -servername <hostname> 2>/dev/null \   | openssl x509 -noout -ext extendedKeyUsage   # List EKUs for every certificate in a Java/PKCS12 keystore keytool -list -v -keystore <keystore-file> -storetype PKCS12

What you’re hunting for in the output is the string TLS Web Client Authentication, or the raw OID 1.3.6.1.5.5.7.3.2. If it’s there today and the certificate came from a public CA, treat it as exposed.

Why the Common Workarounds Are Dead Ends

Three tempting shortcuts, and where each one runs out.

Opt-in flags: DigiCert and Sectigo both still offer enrollment toggles that keep clientAuth alive, for now. Those toggles disappear at each CA’s hard cutoff, even for renewals of certificates you already hold. This isn’t a fix. It’s a countdown with a fixed end date.

Reissuing early: Reissuing today keeps clientAuth alive for one more certificate lifetime. But public certificate lifetimes are shrinking toward 47 days by March 2029 under CA/Browser Forum Ballot SC-081v3, so your next renewal still lands after the cutoff. The cliff moves closer every time you use this trick; it never moves away.

Non-browser roots: Hierarchies like X9 PKI genuinely still support dual EKU certificates, but Chrome and Firefox will not trust them automatically. You would have to distribute that trust to every relying device yourself, which trades a certificate problem for a full trust-distribution problem. That’s rarely a better trade.

The pattern across all three: client identity was never actually the primary purpose of public web trust. It rode along on a certificate built for a different job. The durable fix is a trust model you actually govern.

Expert Take: Build the Separation You Wanted Anyway

Here’s the part worth saying plainly: this migration is a good excuse to build the architecture you probably should have had already. A private PKI purpose-built for client and machine identity gives you EKU and profile control that public CAs were never going to offer: single-purpose serverAuth and clientAuth profiles by default, a dual-EKU profile kept only as a deliberate, temporary migration bridge rather than a permanent habit, and certificate lifetimes measured in hours to days once issuance is automated, which is a security upgrade, not a burden.

It also decouples you from public churn you don’t control. The 47-day lifetime schedule and whatever the next root program policy shift turns out to be stop being your emergency, because the relying parties are yours, the trust anchors live in your own stores, and the rules are the ones you write. And because you control the hierarchy, hybrid and ML-DSA post-quantum profiles become something you can pilot now, ahead of the public ecosystem’s own PQC rollout, rather than a separate future project.

None of that means going back to issuing dual-purpose certificates freely. The same least-privilege logic that justified splitting serverAuth from clientAuth in public TLS applies inside your own hierarchy too.

What a Production-Grade Private PKI Actually Requires

“Build a private CA” is easy to say and genuinely hard to run well. Doing it badly trades a deadline for an outage. Six requirements that separate a production-grade private PKI from a certificate authority that becomes its own incident:

Requirement	What it actually means
HSM-protected key material	Root and issuing CA keys generated and held in FIPS 140-3 validated HSMs, root kept offline, with documented key ceremonies
Issuing tier built for throughput	Sized for real certificate volume with high availability; ACME, SCEP, and EST support so automated issuance keeps pace with short lifetimes
Revocation infrastructure	CRL distribution points and OCSP responders; stapling helps validate server certificates, but client certificate checks in mTLS are typically verifier-initiated CRL or OCSP lookups
Pinned certificate profiles	Every profile pins explicit EKUs, algorithms, and validity periods, with client and server roles separated by profile or sub-CA
CP/CPS and audit readiness	A Certificate Policy, a Certification Practice Statement, key ceremony records, and template governance that stand up to an external assessor
Lifecycle visibility and automation	Continuous discovery plus automated renewal and rotation; manual tracking cannot keep pace with certificates measured in hours or days

Meeting all six is real engineering effort, ongoing operational commitment, and specialized cryptographic expertise most internal teams aren’t staffed to carry alone. That’s the honest reason many organizations choose a managed PKI (PKIaaS) instead of standing this up from scratch.

The Zero-Downtime Migration Blueprint

Four phases, designed so nothing breaks while trust changes hands. The governing rule underneath all four: maintain your old and new certificate chains in parallel during the transition window, revoke nothing until every consumer trusts the new chain, and complete the migration before your CA’s enforcement date, not on it.

Phase	Focus	Concrete steps
01. Discover	Find exposure	Inventory leaf certificates by EKU, map leaf and intermediate chains, identify every mTLS flow, capture renewal timelines
02. Design	Define profiles	Set explicit EKUs, separate client and server profiles, define algorithms and key sizes, design the CRL/OCSP strategy
03. Deploy	Build trust	Deploy the root and issuing tier (or extend through PKIaaS where it makes sense), automate ACME, SCEP, and EST enrollment, distribute trust anchors
04. Cut over	Switch safely	Run old and new chains in parallel, validate full paths in staging, rotate certificates gradually, retire legacy trust after adoption is confirmed

Two failure modes to design against explicitly: migrating on the enforcement date instead of before it, and revoking the old chain before every consumer has actually adopted the new one. Both turn a planned migration into an outage.

How Encryption Consulting’s PKIaaS Fits This Migration

The Deploy phase above is where most teams either move fast or stall for months procuring hardware, staffing 24/7 operations, and writing CP/CPS documentation from scratch. PKI-as-a-Service from Encryption Consulting is built to remove that bottleneck: a fully managed, high-availability, single-tenant PKI, with CA keys secured in FIPS 140-3 Level 3 HSMs, and CertSecure Manager, EC’s CA-agnostic certificate lifecycle management platform, layered on top for estate-wide visibility and automation.

Foundation: Your root CA, subordinate CAs, and OCSP/CRL services are fully hosted, with zero on-premises CA footprint to maintain. HSM-as-a-Service means EC provisions and maintains the FIPS 140-3 Level 3 hardware; CA keys stay inside the HSM, never exportable to software, while key control and ownership remain yours.

Operations: CertSecure Manager gives full-estate visibility and automates discovery, enrollment, renewal, and revocation across public, private, and PKIaaS-issued certificates alike, through ACME, SCEP, and EST. Because the service is fully managed, EC monitors CA health, CRL renewal, HSM status, and certificate expiry around the clock, catching problems before they become the kind of silent outage described earlier in this post.

Governance: EC provides CP/CPS documentation and template governance, role-based access control, and witnessed, documented key ceremonies, the same governance an assessor will ask for during audit. Certificate profiles come purpose-built for exactly this migration, with crypto-agility designed in so hybrid and PQC-ready certificate profiles are available as standards evolve, rather than another migration project down the line.

Mapped against the four-phase blueprint: Discover and Design are typically a joint exercise with your team; Deploy is where PKIaaS does the heaviest lifting, standing up a governed hierarchy in weeks rather than the months a from-scratch build usually takes; and Cutover is supported by CertSecure Manager’s automation so parallel-chain rollout doesn’t turn into a manual, error-prone rollout.

Frequently Asked Questions

What is the clientAuth EKU and why is it being removed from public TLS certificates?

The clientAuth Extended Key Usage (OID 1.3.6.1.5.5.7.3.2) lets a TLS certificate authenticate as a client, in addition to serverAuth’s role of authenticating a server to browsers. Chrome Root Program Policy v1.8 is removing it from public leaf certificates because public issuance only ever validated domain or organization identity, never client authorization, and because a dual-purpose certificate doubles what a stolen key can do.

Is my real deadline Chrome’s March 15, 2027 date, or something else?

Almost certainly something earlier. Public CAs including DigiCert, Sectigo, Let’s Encrypt, Google Trust Services, and SSL.com have all set their own cutoffs ahead of Chrome’s enforcement date, several already in 2025. Check your specific CA’s advisory page rather than planning around the industry-wide date alone.

Can I keep clientAuth working by reissuing or pinning my current certificate?

No. Verifiers compute the effective EKU as the intersection of every certificate in the chain. Once your issuing CA’s hierarchy moves to serverAuth-only, an intermediate certificate can exclude clientAuth for everything beneath it, and reissuing or pinning the leaf certificate does not change that.

What breaks first when clientAuth disappears from my certificates?

Whatever depends on mutual TLS for machine or client identity: service mesh sidecars, partner API gateways, IoT device fleets, VPN clients, and any load balancer or middleware explicitly configured to enforce the clientAuth EKU. The failure doesn’t appear on the enforcement date; it appears at the next certificate renewal, and the next mTLS handshake after that.

Does migrating to a private PKI also help with post-quantum readiness?

Yes, indirectly but usefully. Because you control the hierarchy, you can pilot hybrid and ML-DSA certificate profiles inside your own private PKI well ahead of the public certificate ecosystem’s own post-quantum rollout, turning this migration into a head start rather than a second, separate project later.

Ready to see where you stand?

Run through the discovery checklist above against your own certificate estate this week. When you’re ready to design and deploy the private PKI side, see how PKI-as-a-Service maps to this exact migration, or talk to Encryption Consulting’s PKI team about a discovery and migration assessment.