Public TLS certificates drop client authentication: What breaks for mTLS

The client authentication EKU (id-kp-clientAuth) is the Extended Key Usage value that lets a certificate act as the client credential in a mutual TLS (mTLS) handshake. Public certificate authorities are removing it from TLS certificates because Chrome's Root Program Policy requires certificates issued from March 15, 2027 to assert server authentication only.

If a service in your stack presents a publicly trusted TLS certificate to prove its identity to another service, that certificate now has an end date you didn't choose. DigiCert will fully remove the Client Authentication EKU from its public TLS certificate issuance on March 1, 2027, including renewals, reissues and duplicates. Sectigo's final cutoff is February 10, 2027. Let's Encrypt has already finished: its default classic ACME profile dropped clientAuth on February 11, 2026, and the temporary tlsclient profile was retired on July 8, 2026.

The certificates you hold today keep working. DigiCert and Sectigo both say certificates issued before their cutoffs stay trusted until they expire. The failure arrives at renewal.

When does each CA stop issuing clientAuth?

The dates are set per CA, inside the deadline Chrome set for the whole web PKI:

Read your own CA's notice rather than a summary, because the carve-outs differ. DigiCert lists EU QWAC and EU QWAC PSD2 among the affected products. Sectigo says its PSD2 QWACs keep the Client Authentication EKU for regulatory and interoperability reasons. If you operate under PSD2, which CA signed the certificate decides what happens to it.

Until March 1, 2027, DigiCert customers can still request both EKUs when enrolling through CertCentral or the Services API, and an administrator can set Server and Client Authentication as the account default. That gets you one more certificate lifetime, not a long-term fix.

What does the clientAuth EKU actually do?

The Extended Key Usage extension lists the purposes a certificate's key may be used for. RFC 5280 says that when the extension is present, the certificate must only be used for one of the purposes it lists. The two purposes at issue are id-kp-serverAuth (TLS server authentication) and id-kp-clientAuth (TLS client authentication).

Public TLS certificates have historically carried both. That's why a certificate bought to serve HTTPS also worked as the client credential in a mutual TLS handshake.

Many stacks check the distinction without anyone opting in. OpenSSL's documentation says that when peer certificate verification is enabled, the TLS implementation by default checks the certificate for consistency with TLS server or TLS client use. It also notes that although RFC 5280 describes these OIDs as being for web use, in practice they're used for all kinds of TLS clients and servers. In a stack that checks purpose, a client certificate without clientAuth fails verification during the handshake.

Why is Chrome removing it?

The Chrome Root Program Policy says the Chrome Root Store is relied on solely for TLS server authentication in Chrome, and not for any other PKI use case. Version 1.8 of the policy turns that into a schedule:

• Subordinate CA certificates disclosed on or after June 15, 2026 must assert only id-kp-serverAuth.
• Subscriber certificates issued on or after March 15, 2027 must assert only id-kp-serverAuth.
• From June 15, 2026, hierarchies found in violation are phased out, with the phase-out date set 90 calendar days after the violation is detected.

None of this says client certificates are bad. The policy states that it doesn't apply to client authentication certificates, or to enterprise and private CAs that issue only within their own organization. The web PKI is being narrowed to one job, and client authentication needs its certificates from somewhere else. Let's Encrypt put it plainly when it announced its own change: client authentication isn't typically used on the web, and isn't required on the certificates a website uses.

Why does it break at renewal and not on the cutoff date?

Certificates already issued with clientAuth stay valid until they expire. Sectigo spells out the mechanism: after February 10, 2027, renewals and reissues exclude Client Authentication automatically.

So the outage is scheduled by your own automation. A renewal job replaces a certificate that worked yesterday with one that's identical except for a missing OID. In a stack that checks certificate purpose, the mutual TLS handshake it was feeding then fails verification, and nothing in the renewal logs looks wrong. DigiCert's notice warns that disruption could occur if certificates intended for client authentication carry only the Server Authentication EKU.

How do you find the certificates at risk?

Start with an inventory. The openssl x509 command can print a certificate's EKU and test which purposes it passes:

  
# Which purposes does this certificate claim?
openssl x509 -in service.pem -noout -ext extendedKeyUsage

# Would a validator accept it as a TLS client certificate?
openssl x509 -in service.pem -noout -purpose | grep -i "SSL client"
  

Run that across every certificate your services present, then look closely at places where a publicly trusted certificate does client-side work:

• Partner and regulator integrations that require mutual TLS, where the certificate came from a public CA because the partner wanted a publicly trusted chain.
• OAuth mutual-TLS client authentication. RFC 8705 binds an access token to the client certificate's SHA-256 thumbprint through the cnf.x5t#S256 claim. If that client certificate came from a public CA, it belongs on this list.
• Internal service-to-service mTLS that reused the public certificate already on the host.
• Message brokers, databases and load balancers configured to require a client certificate.

Where should client authentication go instead?

Private PKI is the usual answer for internal use. Sectigo recommends it and advises against using publicly trusted certificates for client authentication at all. Chrome's policy doesn't apply to private or enterprise CAs, so you control what EKUs your certificates carry. The cost is running or buying a CA and distributing its root to every client that needs to trust it.

X9 PKI, governed by ASC X9, is a certificate policy framework independent of the browser root programs, and its TLS certificates can carry both EKUs. It suits certificates that must be recognized across organizational boundaries.

Non-browser public roots are another route DigiCert names: its Assured ID Root G2 (RSA) and G3 (ECC) hierarchies can still issue TLS certificates with clientAuth. DigiCert notes these certificates aren't trusted in Google Chrome or Mozilla Firefox, so they suit backend client credentials, not anything a browser connects to.

Sometimes, no certificate at all. If a client certificate exists only so one of your services can prove its identity to another, an OAuth token can do the same job without a PKI to operate. And if you keep mTLS for OAuth token binding, RFC 8705 also supports self-signed certificate-bound tokens, where the client generates its own certificate and the thumbprint matters, not the chain. We cover the trade-offs between mTLS and DPoP in Sender-constrained tokens: Why mTLS and DPoP exist.

If you use WorkOS, two things are worth knowing. Webhook requests from WorkOS are verified with an HMAC SHA256 signature in the WorkOS-Signature header, not a client certificate, so this change doesn't affect how you receive them. And if you're replacing a client certificate that only proved one of your services to another, Connect M2M applications issue access tokens through the OAuth client_credentials grant, with a client ID and secret instead of a certificate.

What should you do this quarter?

The CA deadlines are in 2027, but the discovery work isn't, and no renewal job will do it for you. Run the two openssl commands across every certificate your services present, find each handshake that works today only because a certificate claimed two purposes, and decide which of the two it needs.