Changes to TLS clientAuth Certificates: Ensuring You’re Not Impacted

Cisco customers and partners who use Cisco equipment and services must be aware of important upcoming changes to public TLS certificates used for client authentication, driven by browser security policies such as those from Google Chrome. These changes affect certificates containing the Client Authentication Extended Key Usage (EKU) and require careful management of certificate trust stores to avoid service disruptions.

This article explains the changes, the role of trust stores, how to verify and update them, and steps to ensure your systems remain secure and operational.

Important Note: This does NOT affect certificates that are issued by private PKI.

What is Extended Key Usage (EKU) and Why It Matters

Extended Key Usage (EKU) defines the specific purposes for which a digital certificate can be used. Two common EKUs in TLS certificates are:

• Server Authentication (OID 1.3.6.1.5.5.7.3.1): This EKU verifies a server’s identity to clients, enabling secure HTTPS connections.
• Client Authentication (OID 1.3.6.1.5.5.7.3.2): This EKU verifies a client’s identity to a server, which is essential for mutual TLS (mTLS) where both parties authenticate each other.

Changes to Public TLS Certificates

The change, to disallow public TLS certificates from containing the clientAuth EKUs, was initiated by Google Chrome’s root store program policies. This may work fine within the boundaries of web-browsing.  However, Cisco’s ecosystem has different security requirements which include trusting root certificates for its services and equipment to securely authenticate both clients and servers.

Important facts:

• From June 15, 2026, public Certificate Authorities (CAs) within Google Chrome’s root store will stop issuing TLS certificates containing both serverAuth and clientAuth EKUs.
• Certificates issued before this date remain valid until their expiration, even beyond June 15, 2026.
• Cisco’s publicly accessible Trusted Root Store bundles will include Root CAs needed for clientAuth validation.

Certificate Authority (CA) and EKU Mapping for Cisco Services

If Cisco customers and partners are currently utilizing the clientAuth EKU in certificates, then it is important to verify that the trust store includes Root CAs that will continue to include the clientAuth EKU. 

Cisco manages its own publicly accessible Trusted Root Store bundles tailored for various types of services. These bundles include the necessary Root CAs to validate certificates used in Cisco services, ensuring secure mutual authentication while aligning with browser root store policies.

Click here for more information on Cisco’s Trusted Root Stores 

Using IdenTrust and Digicert as examples, you can see how the industry is shifting from using the “IdenTrust Commercial Root CA 1” and “Digicert Global Root G2” towards different Root and Issuing/Sub CAs.  This is because the aforementioned Root CAs will remain in the Google Chrome root stores, where they are no longer allowed to issue certificates that contain the clientAuth EKU.

This example illustrates the drive towards new Root CAs for clientAuth needs and the importance of verifying that your services trust them in order to successfully make TLS connections.  

Note: The above Root CAs are all included in Cisco’s Trusted Root Store bundles. 

For more details, see Cisco’s trusted root store bundles: 
Cisco Trusted Root Store Bundles Readme

Understanding Trust Stores and Their Importance

A trust store is a collection of trusted Root CA certificates that your systems use to validate TLS certificates. To avoid disruptions:

• Ensure your systems’ trust stores include the correct Root CAs like those listed above.
• Regularly update trust stores to align with Cisco’s publicly available bundles.
• Missing or outdated Root CAs in trust stores can cause certificate validation failures.

How to Verify What Is in Your Trust Store

General Verification Steps

• Identify the trust store location used by your system or application.
• Use tools such as Keytool (Java), OpenSSL, or platform-specific utilities to list certificates in the trust store.
• Confirm that the new Root CAs you will utilize for clientAuth needs (e.g., IdenTrust Public Sector Root CA 1, DigiCert Assured ID Root G2) are present.

How to Ensure You Are Not Impacted

1. Audit Your Current Certificates and Trust Stores 
   Inventory all public TLS certificates, especially those used for mTLS, and verify the EKUs they contain. Confirm that your trust stores include the correct Root CAs.  Contact your Certificate Authority partner (Digicert, IdenTrust, Sectigo, etc) to ensure you understand which Root CA to trust for clientAuth.
2. Update Trust Stores Regularly 
   Align your trust stores with Cisco’s publicly available trusted root store bundles.
3. Add Missing Root CAs to Trust Stores 
   If a required Root CA is missing, import it into your trust store.
4. Coordinate with Partners 
   Communicate with external partners to ensure their certificates and trust stores comply with the new standards.
5. Monitor Browser and CA Policy Changes 
   Stay informed about browser policies (e.g., Google Chrome) that enforce these changes and website of your chosen Certificate Authority partner.
6. Test 
   Utilizing new CAs requires testing on both the Server and Client sides to ensure the new certificates are trusted.

By auditing your certificates and trust stores now and aligning with Cisco’s trusted root store bundles, you can ensure your Cisco services and equipment continue to operate securely and without interruption.  We encourage impacted organizations to review their current certificate usage and begin planning their migration well ahead of the deadlines.

Reference Document Links: 

1. CUCM Certificate Management and Change Notification – Cisco
2. Security Guide for Cisco Unified Communications Manager, Release 15 and SUs – Default Security
3. Secure Network Analytics SSL/TLS Certificates Guide for Managed Appliances v7.5.3 

We’d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.

Cisco Security Social Media

LinkedIn
Facebook
Instagram
X