Management summary
This blogpost addresses the upcoming changes regarding the removal of Client Authentication Extended Key Usage (EKU) from publicly trusted SSL/TLS certificates, a shift driven by security concerns and the need for clearer roles in cryptographic operations.
Starting in September 2025, major Certificate Authorities (CAs) will begin phasing out the Client Authentication EKU from public certificate issuance, with a final cutoff for this extension by mid-2026.
The primary goal of these changes, according to the CA/B forum is to reduce security risks associated with dual-purpose certificates and enforce stricter guidelines for their use. Organizations relying on mutual TLS or client authentication will need to adopt dedicated client certificates to ensure compliance and maintain secure operations. This blogpost outlines the implications of these changes, the security benefits they offer, and actionable steps for organizations to prepare for this transition.
Introduction
Security and compliance are paramount considerations for organizations utilizing cryptographic certificates for authentication and communication. The removal of the Client Authentication Extended Key Usage (EKU) from SSL certificates will reshape the use of these certificates, particularly for mutual TLS (mTLS) scenarios. This blogpost provides a comprehensive overview of the Client Authentication EKU, its implications, and the timeline for its phased out implementation. By understanding these upcoming changes, organizations can take necessary actions to ensure they remain compliant and secure, while also improving the clarity of their certificate management practices.
What is Client Authentication Extended Key Usage (EKU)?
The client authentication EKU (Extended Key Usage) is a certificate extension that designates a digital certificate for authenticating a client (such as a user or device) to a server, commonly used in mutual TLS (mTLS) scenarios.
It is a feature added to digital certificates that specifies what a public key can be used for. It creates a clear list of approved uses, making sure the key is only used for certain cryptographic tasks. The allowed uses are identified by unique numbers called Object Identifiers (OIDs), which categorize each specific purpose, like code signing, server authentication, client authentication, or secure email.
When someone verifies a certificate, they look at the EKU to find the OID. By including the EKU extension, a Certificate Authority (CA) limits what the certificate can be used for, linking each purpose to a specific OID. Here are a couple of examples:
- TLS Web Server Authentication: The certificate can be used to verify a server, like for an HTTPS website. The OID for Server Authentication is 1.3.6.1.5.5.7.3.1.
- TLS Web Client Authentication: The certificate can be used by a client to verify itself to a server, such as in mutual TLS. The OID for Client Authentication is 1.3.6.1.5.5.7.3.2.
Normally, browsers and servers only require the serverAuth EKU to set up a secure HTTPS connection. However, many TLS server certificates have historically included both serverAuth and clientAuth EKUs.
EKU Usage in PKI
- EKUs restrict a certificate’s permitted roles, such as server authentication, client authentication, code signing, or email protection.
- When client authentication is required (e.g. mTLS), the presence of the clientAuth EKU signals to a system that the certificate can be trusted for that purpose.
- Historically, some server TLS certificates included both serverAuth and clientAuth EKUs, but this practice is being deprecated to reduce security risks and clarify cryptographic roles.
Industry Changes
- Starting in 2025-2026, major CAs and browser root programs (such as Google Chrome) will require separation of server and client authentication EKUs, meaning public TLS certificates should only have serverAuth EKU, and not clientAuth, to prevent misuse and improve security.
- Organizations needing client authentication will now need dedicated client certificates with the clientAuth EKU.
Impact of removing Client Authentication EKU on SSL Certificates
Removing the Client Authentication EKU from SSL certificates means future public server certificates will be used strictly for server authentication and not for client-side purposes like mutual TLS (mTLS).
Impacts on SSL Certificate Usage
- Server certificates issued after mid-2025 will only include the serverAuth EKU, preventing any ambiguous or insecure use as client authentication credentials.
- Existing certificates (issued before deadlines) remain valid until expiration; they will not be retroactively revoked.
- Standard HTTPS web servers are unaffected, as browsers (such as Chrome and Firefox) only check for server authentication and ignore the clientAuth EKU for website access.
- For environments that rely on mTLS or client/device authentication with public SSL certificates, a separate client authentication certificate will be required in the future.
Security and Compliance Benefits
- Reduces risks of misuse and unintentional dual usage, enhancing separation between public internet and internal PKI infrastructures.
- Aligns all Certificate Authorities (CAs) and browsers under stricter guidelines that support secure, single-purpose certificates.
Steps for Organizations
- Review certificate inventories to determine which systems rely on dual-use/server certificates for client authentication.
- Update systems to use dedicated client certificates (with clientAuth EKU) for mutual TLS, device authentication, or server-to-server connections.
- Modify certificate request processes/documentation so future renewals will comply with new policies and avoid service disruptions.
Effects Table
| Use Case |
Change After EKU Removal |
Required Action |
| HTTPS Websites |
No impact; standard SSL continues |
None |
| Mutual TLS (mTLS) |
Server certificates can’t authenticate clients |
Switch to dedicated client certificates |
| Legacy/Enterprise Systems |
Dual-use certs rejected; possible incompatibility |
Update systems, use dedicated client certs |
Removal of the client authentication EKU is a security-driven move to ensure SSL certificates are used for their intended purposes, with minimal impact for most users except those relying on mTLS or mixed authentication environments.
When will CA’s stop issuing certificates with Client Authentication EKU?
Certificate Authorities (CAs) will begin phasing out SSL/TLS certificates with the Client Authentication EKU starting September 2025, with final cut-off dates in mid-2026 depending on the CA.
Major CA Timeline Highlights
- September 15, 2025: Most major CAs, including Sectigo and Trustico, will stop including the Client Authentication EKU by default in new SSL certificates.
- October 1, 2025: DigiCert will stop issuing public TLS certificates with the ClientAuth EKU by default. Special requests may be accommodated until May 1, 2026, after which no public certs can include ClientAuth EKU.
- May 13–15, 2026: Final industry-wide deadlines; all major CAs (including Let’s Encrypt, Sectigo, DigiCert, and Trustico) will permanently remove Client Authentication EKU from new public SSL/TLS certificate issuance, including renewals and reissues.
- June 15, 2026: Google Chrome root program will only trust public SSL certificates with serverAuth EKU, rejecting any with ClientAuth EKU as of this date.
Summary Table
| CA Name |
Default Stop Date |
Hard Deadline |
| Sectigo |
Sept 15, 2025 |
May 15, 2026 |
| DigiCert |
Oct 1, 2025 |
May 1, 2026 |
| Let’s Encrypt |
Early 2026 |
May 13, 2026 |
| Trustico |
Sept 15, 2025 |
May 15, 2026 |
After these deadlines, no new or renewed public SSL/TLS certificates from major CAs will contain the Client Authentication EKU, marking the industry-wide transition.
What security benefits come from removing ClientAuth EKU?
According to the CA/B forum, removing the ClientAuth EKU from publicly trusted SSL certificates brings several key security benefits by enforcing certificate purpose specificity and reducing risks of misuse or misconfiguration.
Separation of Trust Roles
- Public server certificates will be used strictly for server authentication, not for client or device authentication.
- This minimizes the chance of certificates being repurposed beyond their intended function, adhering to the principle of least privilege.
Reduced Risk of Misconfiguration
- Some systems previously accepted any certificate with a ClientAuth EKU for client authentication, leading to possible unauthorized access if a public server certificate was mistakenly trusted.
- Restricting EKUs to their intended uses makes PKI architecture clearer and more robust for maintenance and audits.
Improved PKI Hygiene and Compliance
- Enforcing separate certificate hierarchies for server and client roles aligns Certificate Authorities (CAs) with browser requirements and modern PKI standards.
- Reduces complexity and attack surface from multipurpose certificates, making it easier to manage and secure public and private PKI deployments.
Prevention of Multipurpose Certificate Abuse
- Mixed-use certificates (with both serverAuth and clientAuth EKUs) can be abused if used in unintended authentication schemes, potentially facilitating lateral movement or privilege escalation.
- By requiring separate certificates for each purpose, organizations can better monitor, audit, and control sensitive access scenarios.
Summary Table
| Security Benefit |
Description |
| Role separation (least privilege) |
Prevents certificates from being used outside scope |
| Reduces misconfiguration risk |
Eliminates accidental client/server EKU overlap |
| Enhances PKI architecture |
Allows clear PKI separation, policy enforcement |
| Lowers attack surface |
Disallows unintended access via multipurpose certs |
In summary, removing ClientAuth EKU from server SSL certificates strengthens security by clarifying certificate use, enforcing compliance, and reducing the risk that public certificates are misused for sensitive client authentication scenarios.
How to prepare your systems for the EKU deprecation timeline?
To prepare systems for the Client Authentication EKU deprecation timeline, organizations should take proactive steps to ensure continued secure operations and compliance by the 2025-2026 deadlines.
Preparation Steps
- Inventory Current Certificates and Usage
- Audit all existing SSL/TLS certificates to identify which have Client Authentication EKU included.
- Determine which applications rely on these certificates for client authentication (e.g., mutual TLS, device authentication).
- Determine if and how these applications in need of both a ServerAuth and ClientAuth publicly trusted certificate actually support the configuration of seperate ClientAuth and ServerAuth certificates (and keys). If not, contact the application vendor when this feature will be supported.
- Plan for Certificate Segmentation
- Separate client authentication and server authentication roles by using dedicated certificates for each purpose.
- Obtain client certificates with the ClientAuth EKU strictly for client authentication, and server certificates with ServerAuth EKU only.
- Update Systems and Applications
- Modify client and server software to support distinct certificates for mutual TLS and other client authentication methods.
- Ensure applications validate EKU values correctly to avoid accepting improper certificates.
- Adjust Certificate Management Processes
- Update internal policies and documentation to reflect the new restrictions on EKU usage.
- Coordinate with CAs for certificate issuance without ClientAuth EKU in server certificates after deadlines.
- Test and Validate
- Conduct testing with planned certificate changes in staging or development environments before production roll-out.
- Verify all authentication flows, including mutual TLS, function correctly with new certificate configurations.
- Communicate Changes
- Inform stakeholders, including IT, security teams, and application owners about the EKU deprecation impact.
- Provide training or guidance on new certificate handling and PKI practices.
Summary Table
| Action |
Description |
| Certificate inventory |
Identify certificates with ClientAuth EKU |
| Use dedicated certs |
Separate client and server roles with relevant EKUs |
| System/application updates |
Support and enforce EKU-specific certificate usage |
| Policy/process adjustment |
Reflect EKU deprecation in issuance/renewal policies |
| Testing and validation |
Confirm functionality with new certificate setups |
| Stakeholder communication |
Educate teams about EKU changes and compliance |
By following this roadmap, organizations can minimize operational disruptions and maintain strong PKI security posture through the Client Authentication EKU deprecation transition.
Specific information for KeyTalk customers
KeyTalk’s Certificate and Key Management Solution enables automated renewal of certificates (and private keys), and provides the means to additionally automatically relay, install and configure these certificates on your target end-point for a target application.
KeyTalk customers who have a need for publicly trusted ClientAuth certificates, are advised to:
- Create a new dedicated Certificate Template for the requesting of publicly trusted ClientAuth certificates. The easiest way is to copy your existing multi-purpose certificate template, and change the product to ClientAuth certificate for the relevant public CA. Don’t forget to connect your new certificate template to the Internal Db Registration Authority
- Either manually define the FQDNs for the applications in need of ClientAuth certificates as KeyTalk SEATs, or have these created automatically upon authenticated new certificate requests
- Test if enrollment is succesful and that your KeyTalk CKMS obtained the correct type of certificate.
- Enable ACME when applicable for your new ClientAuth certificate template and note down the unique KeyTalk ACME server url
- Configure where applicable your existing ACME agents running on the end-points hosting the applications in need of the additional ClientAuth certificate, to request an additional certificate coming from the newly enabled ACME url
- Configure where applicable your existing KeyTalk enteroprise agents running on the end-points hosting the applications in need of the additional ClientAuth certificate, to request an additional certificate coming from the newly enabled certificate template, AND where needed update the connected Powershell or Bash scripts to properly apply the obtained ClientAuth certificate to the target application
- Test if the automated ClientAuth certificates are fetched correctly and aplpied correctly to your target application(s).
Do you have questions about this article or how KeyTalk CKMS helps you ease with the management and automation of digital certificates? Our support team is available 24/7 to assist and guide you in implementing a fully automated PKI architecture via e-mail or our contact page.
The KeyTalk Team
