clientAuth EKU Removal

Action is required to maintain service continuity. The removal of the clientAuth EKU from publicly trusted certificates will break any services relying on them for client or machine authentication, for example in a typical mTLS (mutual TLS) setup. The first Chrome deadline (15 June 2026, subordinate CAs) has already passed; publicly trusted subscriber certificates must be serverAuth-only from 15 March 2027, and several CAs stop issuing clientAuth before that. A managed transition to a Private PKI is the most strategic and compliant path forward.

What’s Changing

The End of Public Client Authentication

This change is coming from the Google Chrome Root Program (not the CA/Browser Forum), and in practice it applies to all public CAs that want to remain trusted in Chrome. The CA/Browser Forum may later follow with an alignment ballot, but the operational impact for relying parties is the same.

This direction has been discussed and anticipated for years: browsers have steadily narrowed the WebPKI’s scope to public server authentication, not general-purpose client identity.

Two deadlines, one direction

Chrome phases the change in over two dates, defined in the Chrome Root Program Policy (v1.8):

Effective 15 June 2026 — issuing CAs (already in force): every subordinate CA certificate disclosed to the CCADB on or after this date, operated beneath a root in the Chrome Root Store, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. No new dual-purpose (serverAuth + clientAuth) issuing CA can enter a Chrome-trusted hierarchy, so the pool of public CAs still able to issue clientAuth is frozen and shrinking.

Effective 15 March 2027 — subscriber certificates: all corresponding unexpired and unrevoked subscriber certificates issued on or after 15 March 2027 MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

The subscriber deadline moved, the direction did not. The requirement for subscriber certificates was originally set at 15 June 2026 and has been deferred to 15 March 2027. Treat this as runway, not a reprieve: the deadline that matters in practice is your CA’s cut-off date, and several major CAs stop issuing clientAuth weeks to months earlier.

This change separates the WebPKI’s role (public server authentication) from the role of client identity and access control (private client authentication). It affects any environment using publicly trusted certificates for client authentication, both browser and non-browser, such as VPN access, API gateways, device authentication, or internal service mesh communication.

This does not mean you can’t use client authentication or mTLS; it means client certificates should come from a Private PKI (or equivalent) while server certificates remain publicly trusted for serverAuth.

Scope note: This change is about publicly trusted TLS certificates (the WebPKI). It does not inherently prevent other certificate use cases (for example S/MIME or internal signing/sealing certificates) from including clientAuth, but it’s still recommended to consider a purpose-built clientAuth issuing CA for client identity.

More broadly, expect that root programs may continue to tighten and refine what is acceptable in publicly trusted certificates, and similar constraints could expand to additional public certificate profiles over time.

Key Dates

Public CAs are not waiting for the root program deadline, and their own dates are the ones that decide when your renewals silently lose the clientAuth EKU. The examples below are indicative; always confirm the exact cut-off with your own CA, including for renewals, reissues, and duplicates.

• 1 Oct 2025
  • clientAuth off by default
    • DigiCert stops including clientAuth in public TLS certificates by default; it remains available on request.
• 11 Feb 2026
  • Let’s Encrypt
    • clientAuth dropped from the default ACME profile; the temporary tlsclient profile carried it only through mid-2026.
• 15 Jun 2026
  • Chrome: issuing CAs
    • Newly disclosed subordinate CAs in Chrome-trusted hierarchies must assert id-kp-serverAuth only.
• 10 Feb 2027
  • Sectigo
    • Announced hard stop: no clientAuth in any SSL/TLS certificate.
• 1 Mar 2027
  • DigiCert
    • Announced hard stop, including renewals, reissues, and duplicates.
• 15 Mar 2027
  • Chrome: subscriber certificates
    • All newly issued public TLS certificates must assert id-kp-serverAuth only. Maximum validity drops to 100 days on the same date.
• Autumn 2027
  • Last dual-EKU certificates expire
    • A certificate issued just before 15 Mar 2027 can be valid for at most 200 days, so publicly trusted clientAuth certificates disappear from production around the end of September 2027.

Several CAs, including the large ACME providers, have already stopped issuing publicly trusted TLS certificates that include clientAuth. If you are still receiving them today, you are on borrowed time from a shrinking set of issuers.

Two changes land on the same day. 15 March 2027 also cuts maximum certificate validity from 200 to 100 days. Renewal volume doubles at exactly the moment your remaining public clientAuth certificates have to be replaced — which is why inventory and target architecture decisions belong in 2026, not in the final quarter before the deadline.

Direct Impact of clientAuth EKU Removal

Migration Challenges and Critical Risks

Moving away from public CAs for client identities introduces new strategic, technical, and sometimes compliance challenges that demand timely action and planning. We help you navigate these hurdles.

Identifying every system, application, and device that currently relies on the clientAuth EKU in public TLS certificates is complex and crucial to avoid surprise outages.

Transitioning requires an alternative public certificate purpose or designing, implementing, and securing a new Private PKI hierarchy (Root CA, Intermediate CAs) from the ground up or adopting PKIaaS.

Legacy devices and applications may require certificates based on a specific certificate profile and hierarchy.

Client certificates are often requested and managed by customers or partners, so you may need to coordinate their migration to a new issuance platform or have them obtain client certificates directly from you.

How Digitorus Enables a Secure Migration

We provide a full-service strategy to manage this complex transition, ensuring a seamless move to a compliant, resilient machine identity foundation.

Phased Migration Journey

Our structured approach addresses all technical and compliance requirements before deployment. Plan backwards from your CA’s cut-off date rather than from 15 March 2027: with discovery, architecture decisions, pilots, and partner coordination in the critical path, the replacement of the last public clientAuth certificates needs to be underway well before renewals stop carrying the EKU.

• Phase 1
  • Discover
    • Inventory all affected certificates and map dependencies.
• Phase 2
  • Strategy
    • Determine target architecture: Public, Private PKI, PKIaaS, or alternative method.
• Phase 3
  • Implement
    • Build or adopt the new CA environment and pilot enrollment and authentication.
• Phase 4
  • Migrate
    • Orchestrate the systematic replacement of old public TLS clientAuth certificates.

Supporting Capabilities for Private PKI

Our work is practical and outcome-focused: we work with you to choose the right approach for your environment and make it operable, without forcing a one-size-fits-all “build a PKI” program. That means aligning on the key decisions together (platform, issuance model, trust distribution, key protection) and producing the governance you actually need (controls, risk assessments, and CP/CPS updates where appropriate).

For clientAuth and mTLS, we focus on what breaks in production: consistent certificate profiles (EKUs, subject/SAN strategy), reliable enrollment at scale, partner/customer onboarding, and lifecycle hygiene (renewal, rotation, revocation).

Full-lifecycle support for designing and hardening your new CA hierarchy, including HSM strategy and key management.

Reviewing and updating your Certificate Policy and Practice Statement (CP/CPS) to meet new governance requirements for self-managed identities.

Implementing robust CLM platforms to automate issuance, renewal, and revocation of all private certificates (ACME, CMP, EST, SCEP).

Which New CA is Right for Your ClientAuth?

Public CAs are phasing out multipurpose certs, but the alternative can be complex. Do you need a Shared Public CA or a flexible Private PKI? Get unbiased expert guidance targeted to your usecase before you choose.

Start Your Independent PKI Strategy Session