Removal of the Client Authentication EKU from TLS Server Certificates – What You Need to Know

Overview

Beginning September 15, 2025, SSL.com’s TLS server certificates will be issued without including the Client Authentication extended key usage (EKU) extension. This change is guided by the Google Chrome Root Program Policy. Here , we explain what EKUs are, why this change is occurring, how it might impact server environments, and what actions you may need to take. We also provide an FAQ and technical guidance for various scenarios. 

What are Extended Key Usages (EKUs)? 

Extended Key Usage (EKU), is a certificate extension that defines the intended function of a public key within a digital certificate. It establishes a structured set of permitted applications, ensuring that the key is used only for specific cryptographic operations.  

This functionality is governed by Object Identifiers (OIDs)—unique numerical identifiers that categorize each allowed usage, such as code signing, server authentication, client authentication, or secure email. When authentication is certificate-based, the verifying entity reviews the cert to identify the Object Identifier (OID) within the EKU. By embedding the EKU extension, a Certificate Authority (CA) restricts the certificate’s scope to predefined roles, with each designated purpose explicitly mapped to an OID. 

For example: 

• TLS Web Server Authentication – Indicates the certificate can be used to authenticate a server (e.g. an HTTPS website). The OID corresponding to Server Authentication is 1.3.6.1.5.5.7.3.1 

• TLS Web Client Authentication – Indicates the certificate can be used by a client to authenticate to a server (e.g. a client certificate for mutual TLS). The OID assigned to Client Authentication is 1.3.6.1.5.5.7.3.2 

Browsers and servers only need the serverAuth EKU to establish a secure connection for HTTPS but historically many TLS server certificates included both the serverAuth and clientAuth EKUs.  Below is an example of a such a certificate:

What’s happening? 

Starting September 15, 2025, SSL.com will issue TLS certificates that only include the serverAuth EKU (and not clientAuth) for server certificates. In other words, new SSL/TLS certs for your website or server will explicitly be for “Server Authentication” only. 

Why remove the clientAuth EKU from server certs? 

There are several reasons for this mandate: 

• Security and Scope: Public TLS certificates are only supposed to authenticate servers on the web. The removal provides a clear separation between server and client functionality. The ClientAuth EKU is used for authentication of machines and users with Mutual TLS (mTLS) and other authentication scenarios. 

• Prevent Misconfiguration: Some systems might trust any certificate from a public CA for client authentication if the EKU is present, which could be a security risk. 

• Browser Requirements: Major browsers do not require or check the clientAuth EKU in a website’s certificate.  

• Simplified PKI Architecture: By separating usages, CAs can maintain distinct certificate hierarchies for server TLS vs. other purposes. 

Industry Compliance 

This policy change is currently being phased in by the Google Chrome root program.  

Impact on Server Environments 

For the vast majority of server deployments, this change will be low-impact or no-impact. Here’s what to expect: 

• Standard Web Servers (HTTPS): No impact. The updated certificates will continue to function normally. 

• Existing Certificates: Any certificate issued before the cutoff will continue to function until it expires. 

• Mutual TLS (mTLS) and Client Cert Scenarios: If you were using a TLS server certificate for client authentication, you will need to obtain a separate certificate with the clientAuth EKU from another source.  

• Enterprise Systems Requiring Both EKUs: Some legacy or enterprise systems expected both EKUs. You should verify if updates are needed to comply with the new rules. 

• Certificates for API Clients, IoT devices, etc.: If your use case relied on clientAuth EKU, you will need to obtain a dedicated client authentication certificate. SSL.com does offer Client Authentication Certificates. 

Required Actions for Customers 

1. Inventory your Certificates: Identify any TLS certificates in use and check for the clientAuth EKU. 
2. Identify Any Dual-Use Cases: Determine if any of your systems rely on a TLS certificate for client authentication. 
3. Plan for Certificate Renewal/Reissuance: Future certificates will be issued without clientAuth EKU by default. 
4. Reissue Early if Needed: If you want to proactively update your certificates, you can reissue them before the deadline. 
5. Obtain Client Authentication Certificates if Required: Secure a separate certificate with the clientAuth EKU if needed. 
6. Update Documentation and Configuration: Modify any automated certificate request scripts or documentation that previously assumed both EKUs would be present. 

FAQ (Frequently Asked Questions) 

Q1. What is the “Client Authentication” EKU and why was it in my certificate? 

The “Client Authentication” EKU indicates a certificate can be used by a client to authenticate to a server. Some CAs historically included it in TLS certificates by default, but it was never required for normal website security. 

Q2. Will browsers reject my certificate if it has the clientAuth EKU after September 15? 

No, browsers will not suddenly start rejecting existing certificates that have the clientAuth EKU. The change is about new issuance. 

Q3. My current TLS certificate says “Client Authentication” under its Extended Key Usage. Is it now invalid? 

No, it remains valid. You don’t need to replace it immediately. When you renew, the new certificate simply won’t include the clientAuth EKU. 

Q4. How can I check if a certificate has the clientAuth EKU? 

You can inspect the certificate details using OpenSSL, PowerShell, or GUI tools to check for the Extended Key Usage extension. 

Q5. Our system requires the server certificate to have both serverAuth and clientAuth EKUs. What should we do? 

You should update your system to only require serverAuth for server certificates. If client authentication is needed, obtain a separate certificate with the clientAuth EKU from SSL.com. 

Q6. Can I still get a publicly trusted certificate with only Client Authentication EKU? 

Some CAs, like SSL.com, offer dedicated client authentication certificates. These are separate from TLS certificates and typically used for enterprise authentication. 

Q7. Does this affect other EKUs or certificate types (code signing, email, etc.)? 

No, this change is specific to TLS server certificates. Code signing and email certificates have their own EKU requirements. 

Q8. We use client certificate authentication on our website. Does this change affect that? 

No, mutual TLS (mTLS) authentication still works. However, ensure that client certificates presented by users still have the clientAuth EKU if required. 

Q9. Is this related to the upcoming change to shorter certificate lifetimes (90-day certificates)? 

No, these are separate industry changes, though both aim to improve security and certificate management practices. 

Q10. Where can I see the official requirements about this change? 

The Google Chrome Root Program Policy  provides guidelines on the prohibition of the clientAuth EKU in TLS server certificates. 

Summary 

The removal of the clientAuth EKU from TLS server certificates is an industry-wide policy change that will enhance security and prevent misuse. For most users, there will be no noticeable impact. However, if you rely on the clientAuth EKU, you should take proactive steps to obtain the correct type of certificate for your needs. 

If you have any questions or need assistance, please contact our support team at support@ssl.com.