This transformation affects millions of SSL TLS certificates currently deployed in production systems worldwide. While most standard website HTTPS implementations will see no impact, organisations that rely on client authentication in their public TLS certificates must begin planning their migration strategy immediately to avoid service disruptions.
What is Client Authentication EKU, and why is it Being Removed?
Extended Key Usage (EKU) is a certificate extension defined in X.509 digital certificates that specifies the exact cryptographic functions a certificate's key is permitted to perform. Unlike the basic key usage extension, which applies to general cryptographic operations such as digital signature or key encipherment, the authentication EKU provides granular, purpose-based restrictions using specific Object Identifiers (OIDs).
The client authentication EKU, identified by OID 1.3.6.1.5.5.7.3.2, specifically designates a certificate for client authentication with servers. This capability has been widely used in mutual TLS (mTLS) scenarios, VPN connections, and secure API communications, where both the client and the server must authenticate each other's identities.
Historically, many Certificate Authorities issued public TLS certificates containing both server authentication (OID: 1.3.6.1.5.5.7.3.1) and client authentication EKUs. This dual-purpose approach allowed a single SSL/TLS certificate to serve both roles—securing websites and authenticating clients—making it convenient for enterprise PKI deployments.
However, the Google Chrome Root Program Policy v1.6 now mandates separating server and client authentication roles. The policy explicitly requires that public TLS server certificates must only express "serverAuth" EKU and not "clientAuth." This change is designed to enforce certificate purpose specificity and eliminate the security risks associated with multi-purpose certificates.
The authentication extended key usage separation addresses several critical security concerns:
- Reduced attack surface: Preventing compromised certificates from being misused for unintended cryptographic roles
- Precise purpose specification: Each certificate serves only one authentication purpose
- Simplified validation paths: Browsers and operating systems can enforce stricter rules
- Enhanced compliance: Alignment with industry best practices for certificate management practices
Timeline and Implementation Deadlines by Major Certificate Authorities
The transition away from client authentication EKU in public TLS certificates follows a coordinated industry timeline, with different Certificate Authorities implementing changes on specific dates:
DigiCert has announced a gradual phase-out, with the complete removal of the Client Authentication EKU by May 1, 2026. Organisations relying on DigiCert for dual-purpose certificates should contact their support team to discuss migration timelines and alternative solutions.
Sectigo begins the transition for eIDAS Qualified Website Authentication Certificates (QWAC) on April 7, 2025, with all other public TLS certificates following by May 15, 2026.
Google Chrome and any software relying on the Chrome Root Store will reject server certificates containing both "serverAuth" and "clientAuth" EKUs starting June 15, 2026. This final cutoff marks the hard deadline by which certificate authorities must ensure full compliance.
Existing certificates issued before these cutoff dates that include client authentication extended key usage will remain valid until their normal expiration. The enforcement applies specifically to new SSL certificates, renewals, and reissuances beyond each CA's policy date.
Who will not be Affected:
The vast majority of websites and web applications using SSL certificates solely for HTTPS encryption will experience no impact. Standard e-commerce sites, blogs, corporate websites, and most web services securing websites with basic TLS server certificates will continue operating normally.
Security Benefits of Removing Client Authentication EKU
The elimination of client authentication EKU from public TLS certificates delivers significant security improvements that align with modern certificate management practices and enhance the overall PKI ecosystem.
Primary Migration Options:
Organisations have three main paths for addressing the client authentication EKU removal:
- Transition to Private PKI Solutions
- Obtain Separate Client Authentication Certificates
- Redesign Authentication Architecture
Private PKI vs Public PKI for Client Authentication
Private PKI solutions offer the most comprehensive alternative for organisations requiring continued dual-purpose certificate functionality.
Benefits of Private CA Solutions:
- Unlimited EKU Control: Private certificate authorities can continue issuing certificates with any combination of extended key usages
- Custom Certificate Profiles: Organisations can design certificate templates that meet specific operational requirements
- Enhanced Security Control: Complete management of the trust chain and certificate lifecycle
- Regulatory Compliance: Better alignment with industry-specific requirements and internal security policies
Dedicated Client Certificate Strategy:
For organisations preferring to maintain public PKI, obtaining separate client authentication certificates provides a compliant alternative:
- Request dedicated client certificates from public CAs that include only client authenticationEKU
- Deploy these certificates alongside existing server certificates for mutual TLS scenarios
- Implement certificate management automation to handle multiple certificate types per system
The new X9 Client Auth Certificate from DigiCert
To order an mTLS-compatible certificate today, you can use the new DigiCert X9 Certificate. This won't be compatible with browsers due to Google's untrust of Client Auth EKU, but can be used in setups where Client Auth is required. The new DigiCert X9 Client Auth Certificate is designed to enhance security and compliance within financial services and other sectors that require strong client authentication. It may require installing the provided X9 Root Certificate.
FAQ
Will existing certificates with Client Authentication EKU stop working immediately?
No, existing certificates will remain valid until their natural expiration date. The policy changes apply only to new certificates, renewals, and reissuances issued after each Certificate Authority's cutoff date. However, Google Chrome will begin rejecting new certificates containing both serverAuth and clientAuth EKUs starting June 15, 2026.
Can I still use the same certificate for both server and client authentication after 2026?
Not with publicly trusted certificates. After the implementation deadlines, public Certificate Authorities will only issue TLS server certificates with server authentication EKU. You'll need separate certificates: one for server authentication and another dedicated client authentication certificate for client authentication scenarios. Private PKI solutions can still support dual-purpose certificates.
What happens if I try to renew a certificate with clientAuth EKU after the deadline?
The Certificate Authority will issue a new SSL certificate that only includes server authentication EKU, regardless of your previous certificate configuration. If you need client authentication capabilities, you must request a separate client authentication certificate or migrate to a private CA solution.
Will this change affect other certificate types, like code signing or email certificates?
No, this policy change only affects public TLS certificates used for HTTPS and server authentication. Code signing certificates, secure email (S/MIME) certificates, and other specialised digital certificates are not impacted by the client authentication EKU removal from TLS certificates.
Discussions and Comments
Click here to view and join in on any discussions and comments on this article.
