The dual-EKU TLS certificate removal ends the longstanding practice of issuing a single public certificate with both Server Authentication and Client Authentication extended key usages. From mid-2026, public CAs will only issue certificates containing the serverAuth EKU. Organizations running mTLS or server-to-server authentication with public TLS certificates must migrate to dedicated client authentication certificates before their CA’s enforcement deadline.
What Is a Dual-EKU TLS Certificate?
A dual-EKU TLS certificate is an X.509 certificate containing two Extended Key Usage values: Server Authentication (OID 1.3.6.1.5.5.7.3.1) and Client Authentication (OID 1.3.6.1.5.5.7.3.2). For years, public certificate authorities issued these dual-purpose certificates by default. This made it possible for a single public certificate to secure an HTTPS server and simultaneously authenticate that same server as a client in how mTLS authentication works scenarios.
The CA/Browser Forum EKU policy change, driven by the Google Chrome Root Program Policy v1.6, now mandates that public TLS server certificates must express only serverAuth. The Chrome Root Program will reject any PKI hierarchy issuing certificates that contain both EKUs starting in 2026.
The client authentication EKU is identified by OID 1.3.6.1.5.5.7.3.2. It signals that a certificate’s public key is valid for authenticating the certificate holder as a client to a server – the core requirement of mutual TLS. By removing this EKU from public server certificates, the industry enforces a strict separation between server-side and client-side cryptographic roles.
Why Certificate Authorities Are Removing the clientAuth EKU
Public TLS certificates are designed to authenticate servers to browsers on the open internet. Including the clientAuth EKU in those same certificates created a security risk: any system that trusted a public CA could potentially accept a server certificate as a valid client credential, even when the CA had no way to validate the client identity it was authenticating.
The Chrome Root Program clientAuth policy eliminates this ambiguity. According to the RSAC Conference analysis, root programs including Chrome, Mozilla, Apple, and Microsoft will all enforce this policy from May 2026.
Three concrete security problems drive this change:
- Misconfiguration risk: systems trusting any public CA certificate with clientAuth EKU for authentication, bypassing intended access controls
- Scope creep: public CAs cannot validate client identity the way they validate server domain ownership
- PKI complexity: separate certificate hierarchies for server and client authentication are easier to audit and revoke individually
How This Change Affects mTLS and Server-to-Server Authentication
Mutual TLS authentication requires a client certificate with the clientAuth EKU. For a TLS vs mTLS security comparison, the key distinction is that in mTLS both parties present certificates – the server’s serverAuth certificate and the client’s clientAuth certificate. Historically, organizations running server-to-server mTLS often used one dual-EKU public certificate for both roles.
After the clientAuth EKU deprecation deadlines, renewed public TLS certificates will contain only the serverAuth EKU. Any mTLS implementation presenting that renewed certificate as the client credential will fail authentication. The server receiving it will see a certificate missing the clientAuth EKU and reject the handshake.
The following systems face direct disruption if they use public TLS server certificates for client authentication:
- API gateways and microservice meshes using server-to-server mTLS
- VPN gateways that verify client identity through certificate EKU inspection
- IoT device fleets presenting public server certificates as client credentials
- Financial services platforms using mTLS for transaction authentication
- Enterprise systems that check for clientAuth EKU before allowing connections
Standard HTTPS websites are not affected. Browsers only check for the serverAuth EKU when establishing an HTTPS connection. Your web server’s TLS certificate will continue to work normally.
CA Deadline Comparison: clientAuth EKU Removal Timeline
The following table summarises the enforcement dates from major public certificate authorities, as documented by SSL Trust’s clientAuth EKU analysis and DigiCert’s official transition guide:
| Certificate Authority | Default Off (No clientAuth) | Full Removal Deadline |
| DigiCert | October 1, 2025 | March 1, 2027 |
| Sectigo | October 14, 2025 | May 15, 2026 |
| SSL.com | September 15, 2025 | TBD (Chrome enforcement June 15, 2026) |
| Let’s Encrypt | Rolling (new issuance) | May 13, 2026 |
| Google Trust Services | Phased (post-Sept 2025) | April 13, 2026 |
| Chrome Root Store (enforcement) | — | June 15, 2026 (hard deadline) |
What to Do If You Rely on Dual-EKU TLS Certificates
The first step is a certificate inventory for mTLS: identify every certificate in use and check whether it contains both the serverAuth and clientAuth EKUs. Use OpenSSL to inspect any certificate: openssl x509 -in cert.pem -noout -text | grep -A5 ‘Extended Key Usage’.
Once you identify dual-EKU certificates serving client authentication roles, follow these 4 migration steps:
- Audit your certificate inventory: document every certificate, its EKUs, its expiry, and which service presents it as a client credential
- Identify your replacement path: choose private PKI, PKI-as-a-service, or a sector-specific public PKI (e.g., DigiCert X9 for financial services)
- Obtain dedicated client authentication certificates: these contain only the clientAuth EKU and are issued by a CA or PKI you control
- Update your systems: configure each mTLS endpoint to present the new dedicated client certificate, then revoke or retire the dual-EKU certificate
Organizations that need public CA client authentication beyond the Web PKI can use DigiCert’s X9 PKI, which operates under ASC X9 standards independently from the Chrome Root Store and is permitted to issue certificates with both EKUs. For strictly internal use, a private PKI for mTLS gives you full control over EKU values and certificate lifecycle. Learn more about the tradeoffs in our guide to private CA vs public CA certificates.
Frequently Asked Questions About Dual-EKU TLS Certificate Removal
What is a dual-EKU TLS certificate?
A dual-EKU TLS certificate contains both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) extended key usages in a single X.509 certificate. This allowed one public certificate to serve both server-side HTTPS and client-side mTLS authentication. Public CAs are now prohibited from issuing these dual-purpose certificates under the CA/Browser Forum EKU policy.
How does removing clientAuth EKU affect mTLS?
The clientAuth EKU removal means that publicly trusted TLS server certificates can no longer serve as client credentials in mutual TLS authentication. Any mTLS implementation that presented a public server certificate as the client certificate will break upon renewal after the CA’s cutoff date. Organizations must replace those server certificates with dedicated client authentication certificates issued by a private CA or a sector-specific public PKI like DigiCert X9.
What happens to existing dual-EKU certificates after the deadline?
Existing dual-EKU certificates issued before each CA’s cutoff date remain valid until their natural expiration. Certificate authorities will not retroactively revoke them. However, upon renewal or reissuance after the deadline, the new certificate will only contain the Server Authentication EKU – the clientAuth EKU will not be included regardless of the previous configuration.
What should organizations do to replace dual-EKU TLS certificates?
Organizations that rely on dual-EKU certificates for mTLS must audit their certificate inventory and identify every system presenting a public TLS server certificate as a client credential. The replacement path is a dedicated client authentication certificate issued from a private CA, a managed PKI-as-a-service solution, or a sector-specific public PKI such as DigiCert X9. Standard HTTPS-only deployments require no action.
Does the clientAuth EKU removal affect HTTPS websites?
Standard HTTPS websites are not affected by the clientAuth EKU removal. Major browsers including Chrome and Firefox only check for the Server Authentication EKU when validating a server certificate for HTTPS connections. The removal applies exclusively to the dual-purpose use of public TLS server certificates as client credentials in mTLS and server-to-server authentication scenarios.
What is the deadline for removing clientAuth EKU from public TLS certificates?
The key deadlines for the clientAuth EKU deprecation are: DigiCert stops including it by default from October 1, 2025, with full removal by March 1, 2027. Sectigo fully removes it from all new certificates by May 15, 2026. Google Chrome will reject public server certificates containing both EKUs starting June 15, 2026. Let’s Encrypt enforces full deprecation by May 13, 2026.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
