Public TLS certificates are losing the client authentication purpose, so any mutual TLS connection where one side presents a publicly trusted server certificate as its client certificate will stop working when that certificate is renewed. The Chrome Root Program is phasing out multi-purpose CA hierarchies from the Chrome Root Store, and public CAs are removing the id-kp-clientAuth extended key usage (EKU) from TLS certificates to comply. Browsers are not the casualty here: server-to-server and business-to-business mTLS, partner API gateways and integrations that reused a public web certificate as a machine identity are. This guide gives the official dates, how to find affected connections and certificates, the private PKI and other migration options, and how to test and roll back. It is for PKI, platform and integration engineers. It does not cover certificate lifetimes: see the Certificate Expiry Outages and 47-Day TLS Certificates Guide. Dates checked 8 November 2026.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- The subscriber deadline moved. Chrome Root Program Policy 1.7 set 15 June 2026 for serverAuth-only subscriber certificates; Version 1.8 (5 February 2026) requires it for certificates issued on or after 15 March 2027.
- Your CA may cut off earlier. CAs set their own schedules inside that window: for example, one public CA's ACME client authentication profile was retired on 8 July 2026, and another sets 1 March 2027 as its final date.
- Existing certificates keep working until expiry. The break comes at renewal, when the new certificate arrives without clientAuth and a peer that checks EKU rejects it.
- Client authentication is a private PKI job. Chrome's own non-normative roadmap calls client authentication a private PKI use case; the long-term fix is a private CA, SPIFFE-style workload identity or a non-browser public PKI, not a hunt for a CA that still issues the EKU.
- Inventory both directions. You are affected if you present a public certificate as a client, or if you accept partners' public certificates as client credentials.
What is changing and why
Section 1.3.2 of the Chrome Root Program Policy states that the Chrome Root Store is relied on solely for TLS server authentication and is not used for TLS client authentication, secure email or code signing. To align every hierarchy with that principle, Chrome is phasing out "multi-purpose" roots. A hierarchy is "dedicated" when it serves one use case. The policy's introduction also states that it does not apply to client authentication certificates or to enterprise CAs that are not trusted by default.
The TLS Baseline Requirements (Version 2.3.1, section 7.1.2.7.10) still list id-kp-serverAuth (1.3.6.1.5.5.7.3.1) as MUST and id-kp-clientAuth (1.3.6.1.5.5.7.3.2) as MAY. The removal is therefore driven by root program policy, not by a Baseline Requirements ballot. Chrome's "Moving Forward, Together" roadmap explains the reasoning: Chrome transitively trusts over 2,300 CA certificates, only about half of which issue TLS server certificates, and serving client authentication from public hierarchies ties subscribers to web PKI rules that do not fit their use case. See the CA/Browser Forum Baseline Requirements Guide.
Official timeline and current status
| Date | Event | Source |
|---|---|---|
| 15 June 2025 | New applicant hierarchies: subordinate CAs disclosed from this date must be serverAuth only | Chrome Root Program Policy 1.8, section 2.3 |
| 1 October 2025 | Example CA (DigiCert) stops adding clientAuth by default; opt-in remains | DigiCert knowledge base alert |
| 11 February 2026 | Example CA (Let's Encrypt) default "classic" ACME profile drops clientAuth; "tlsclient" profile available for opt-in | Let's Encrypt announcement (updated 16 March 2026) |
| 13 May 2026 | Let's Encrypt cutoff for starting to use the tlsclient profile | Let's Encrypt announcement |
| 15 June 2026 | Chrome begins phasing out non-compliant hierarchies (phase-out date set 90 calendar days after a violation is detected); subordinate CAs disclosed to the CCADB from this date must assert only serverAuth | Chrome Root Program Policy 1.8, section 1.3.2 |
| 8 July 2026 | Let's Encrypt tlsclient profile retired; no more certificates with clientAuth | Let's Encrypt announcement |
| 1 March 2027 | DigiCert final removal of clientAuth from public TLS issuance, including renewals and reissues | DigiCert knowledge base alert |
| 15 March 2027 | All subscriber certificates issued under Chrome-trusted roots must assert only serverAuth | Chrome Root Program Policy 1.8, section 1.3.2 |
| End of 2027 | Chrome expects the multi-purpose root phase-out to complete (non-normative) | Chrome "Moving Forward, Together" |
CA examples are listed alphabetically and are illustrative, not a comparison: check your own CA's notice. Status on 8 November 2026: the 15 June 2026 hierarchy rule is in force, at least one major ACME CA has stopped issuing clientAuth entirely, and the final subscriber date is 15 March 2027 as published in Policy 1.8. Chrome phases out a practice by placing an SCTNotAfter constraint on the root, so certificates issued before the phase-out date remain trusted in Chrome until expiry. Policy dates have moved once already; recheck the policy before each planning cycle.
Who and what is affected
| Pattern | Typical example | Affected? |
|---|---|---|
| Ordinary HTTPS websites and APIs | Browser or API client verifies the server | No |
| Outbound mTLS presenting a public certificate as client credential | Your service calls a partner or payment API with your web certificate | Yes, at next renewal |
| Inbound mTLS accepting public certificates from clients | Your API gateway trusts public roots and requires clientAuth from partners | Yes, as partners renew |
| Server-to-server federation using the same certificate both ways | Messaging or federation servers that authenticate each other with their domain certificates | Yes |
| Private CA client certificates | Internal service mesh, device certificates, VPN users | No, the Chrome policy does not apply |
| Browser client certificates for users | Smart card or user certificates from private or dedicated client CAs | No, unless issued from a public TLS hierarchy |
Whether a peer actually fails depends on its software: most TLS libraries check that a presented client certificate's EKU permits client authentication when the EKU extension is present, so a serverAuth-only certificate is rejected during the handshake. The identity angle matters too: a public certificate used as a client credential is a non-human identity, often with no owner and a private key copied between servers. See the mTLS Guide.
Finding affected systems and identities
- Certificate inventory: from your certificate management platform, CA portal exports or ACME account history, list every public TLS certificate whose EKU includes Client Authentication. Certificate Transparency logs show every public certificate for your domains, which helps find certificates ordered outside central processes.
- Client-side usage: search configuration for client certificate settings in HTTP clients, integration platforms, API gateways' upstream TLS settings and partner connectors, and match the referenced certificate files or vault entries against the inventory.
- Server-side acceptance: on gateways, load balancers and applications that request client certificates, check the configured client CA bundle. A bundle containing public roots means you accept public certificates as client credentials; list the partners using them from TLS handshake logs (client certificate subject and issuer).
- Handshake telemetry: enable logging of client certificate issuer, subject and EKU where your proxy supports it, and alert on handshake failures with certificate purpose or "unsupported certificate purpose" style errors after renewals.
- Partner outreach: ask each B2B counterparty whether they authenticate to you, or expect you to authenticate to them, with a public certificate, and on what date their CA stops issuing clientAuth.
Metrics: (1) public certificates still carrying clientAuth, with expiry dates; (2) mTLS connections relying on public certificates, by partner; (3) connections migrated to a private or dedicated client PKI; (4) client authentication handshake failures per week; (5) days between your CA's cut-off and the last renewal of each affected certificate.
Migration options
| Option | When it fits | Trade-offs |
|---|---|---|
| Private CA for client certificates | You control both ends, or partners agree to trust your CA | You run issuance, revocation and trust distribution; full control of profiles and lifetimes. See the Private CA Design and Operations Guide |
| Per-partner trust (each side issues to the other) | A small number of B2B links | Simple to agree; scales badly beyond a few partners |
| Workload identity (SPIFFE or service mesh) | Internal service-to-service traffic | Short-lived automated identities; needs platform support. See the SPIFFE and SPIRE Guide |
| Non-browser public PKI | Multi-organisation networks that need a shared public trust anchor | CAs offer hierarchies outside browser root stores that allow clientAuth (DigiCert names an X9 PKI and roots not trusted by Chrome or Firefox); both parties must add the anchor |
| Replace mTLS with token-based authentication | The peer supports OAuth client credentials or private key JWT | Changes the protocol; can be paired with certificate-bound tokens |
| Short-term: renew early with clientAuth | Bridging until a planned migration | Only while your CA still offers it; buys at most one certificate lifetime, which is shrinking |
Decision guidance: internal traffic should move to a private CA or workload identity platform now. For external partners, a private CA works where you can distribute your trust anchor and pin acceptance to the partner's issuing CA and subject; a shared non-browser public PKI suits sectors where many organisations interconnect. Small organisations with one or two affected integrations can often agree per-partner certificates in weeks; large estates should stand up a dedicated client authentication CA, publish its profile, and migrate partners in waves.
Testing and rollback
- Test serverAuth-only now: obtain a serverAuth-only certificate (Let's Encrypt's tlsserver profile already excluded the EKU) and present it to each peer in a test environment to see which ones fail.
- Dual trust on the server side: add the new private client CA to the accepted client CA bundle alongside the current one, so partners can switch on their own schedule.
- Pin identity, not just the chain: map each partner to an expected issuer and subject or SAN, so adding a CA does not admit everyone it signs.
- Switch per connection: move one partner at a time; monitor handshake failures and business transactions for a full cycle.
- Rollback: keep the old public certificate and its key available until it expires, and retain the old CA bundle entry until every partner has switched. Rollback is impossible after your CA's cut-off for new clientAuth certificates, so finish migration before the current certificate expires.
- Remove public roots: once migrated, delete public roots from client CA bundles so a public certificate can no longer authenticate as a client.
Risks of doing nothing
- Outages at renewal: automated renewal quietly issues a serverAuth-only certificate and the partner integration fails at 2am, often without obvious error messages.
- Unsafe workarounds: disabling EKU checking or accepting any certificate from public roots lets any holder of a web certificate authenticate as a client (ATT&CK T1557 Adversary-in-the-Middle becomes easier where validation is weakened).
- Key sprawl: a shared public certificate and key copied to many servers is an unmanaged machine credential; theft maps to T1649 Steal or Forge Authentication Certificates.
- Stalled partners: counterparties who wait for the 15 March 2027 deadline may find their CA stopped earlier.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-17, IA-5(2), IA-3 | PKI certificate issuance under an appropriate policy, public key-based authentication, device and service authentication |
| NIST SP 800-53 Rev 5 | SC-8(1), CM-8 | Cryptographic protection in transit; inventory of components and their certificates |
| NIST CSF 2.0 | PR.AA-03, PR.DS-02, ID.AM-08 | Services authenticated, data in transit protected, assets managed through their life cycle |
| MITRE ATT&CK v20 | T1649, T1557 | Certificate theft or forgery; interception where client validation is weakened |
Practitioner checklist
- Read section 1.3.2 of the current Chrome Root Program Policy and your CA's clientAuth notice; record both dates.
- Export all public certificates with Client Authentication EKU and their expiry dates.
- List every outbound connection that presents a public certificate as a client credential.
- List every inbound endpoint whose client CA bundle contains public roots, and the partners using it.
- Test each peer with a serverAuth-only certificate in a non-production environment.
- Choose the target: private CA, workload identity, non-browser public PKI or token-based authentication.
- Add the new client CA alongside the old trust, pinned to expected issuers and subjects.
- Migrate partner by partner, monitoring handshake failures.
- Remove public roots from client CA bundles after the last migration.
- Assign an owner and rotation process to every new client certificate.
Standards and references
- Google Chrome: Chrome Root Program Policy (Version 1.8)
- Google Chrome: Chrome Root Program policy repository and archive
- CA/Browser Forum: TLS Baseline Requirements
- Let's Encrypt: Ending TLS Client Authentication Certificate Support in 2026
- DigiCert: Sunsetting client authentication EKU from DigiCert public TLS certificates
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: mTLS Guide · Private CA Design and Operations Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Certificate trust stores and root CA management