This is to inform you of an upcoming Google Chrome browser policy change that impacts the issuance of public TLS certificates and to outline the actions Cisco will take to ensure continued support for mutual TLS (mTLS) connections in Cisco Webex Calling Dedicated Instance and UCM Cloud environments.

Beginning in February 1^st 2027, Public Certificate Authorities (CAs) included in the Google Chrome Trust program will stop signing certificates that include the Client Authentication (clientAuth) Extended Key Usage (EKU).

Effective March 15^th 2027, Google will enforce a policy requiring that Public Root CAs in the Chrome Root Store issue certificates containing only the Server Authentication (serverAuth) EKU. As a result, Public Root CAs in the Chrome Root Store will no longer be permitted to issue certificates that combine both Server Authentication and Client Authentication EKUs in a single certificate.

Dedicated Instance UC applications currently use certificates that include both Server Authentication and Client Authentication EKUs within a single certificate to establish trust for mTLS connections. Support for separate server and client certificates is expected to be introduced with the UC application release v15SU5, planned for later in 2026.

Currently, Dedicated Instance uses the IdenTrust Commercial Root CA 1, part of the Google Chrome Root Store, to sign these certificates. However, due to the upcoming Chrome policy change, this CA will no longer be permitted to issue certificates containing both EKUs in a single certificate starting February 1^st, 2027.

Certificates impacted

The following UC application certificates are signed using a Public Root CA and are commonly used for mTLS connections:

UC application	Certificate type	Common mTLS connections
Cisco Unified CM / SME	Tomcat / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth over MRA, Remote Syslog
	CallManager / CallManager-ECDSA	SIP Trunks, Inter-node and Inter-cluster connections
Cisco Unity Connection	Tomcat / Tomcat-ECDSA	SIP Proxy, SIP Trunks
Cisco IM and Presence	Tomcat / Tomcat-ECDSA	—
	cup / cup-ECDSA	Secure SIP with CUCM, third-party clients, SIP Proxy
	cup-xmpp / cup-xmpp-ECDSA	XMPP Federation
Cisco Emergency Responder	Tomcat / Tomcat-ECDSA	—
Cisco Expressway	Server Certificate	Mobile and Remote Access (MRA)

Certificates not impacted

All remaining certificates in Dedicated Instance are self-signed. For additional information, see Dedicated Instance certificate management.

To address the Chrome policy change and maintain uninterrupted mTLS functionality, Cisco will take the following action:

• Effective June 1^st, 2026, Cisco will switch the Public Root CA used for signing Dedicated Instance UC application certificates from IdenTrust Commercial Root CA 1 to IdenTrust Public Sector Root CA 1 for all Certificate Renewals.

  The certificate renewal process remains the same, and the Control Hub Alerts Center notifies customers through the "Maintenance and Outage" alert when the renewal is scheduled. For more information, see Maintenance alerts.

• Certificates will continue to include both Server and Client Authentication EKUs.

Customers and partners must complete the following actions to ensure continued service compatibility :

1. Audit Current mTLS Connections
   1. Identify public TLS certificates that include the Client Authentication EKU.
   2. Verify whether the connecting applications trust the new Public Root CA .
2. Add the New Public Root CA (if required)
   1. If the IdenTrust Public Sector Root CA 1 is not already trusted in your environment, it must be added.
   2. The root certificate can be downloaded from the IdenTrust public repository.

The IdenTrust Public Sector Root CA 1 is trusted by default in the standard trust stores for the following operating systems and platforms:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

As a result, no customer action is required for endpoints or systems using default trust stores on these platforms, unless the trust store has been explicitly modified or restricted by customer policy.

Android trust store note

The IdenTrust Public Sector Root CA 1 is included in the Android system CA store and is trusted by default on currently supported Android versions. Android does not provide a public, version-specific mapping for individual root certificate introduction dates. Trust is managed through the Android system CA store and distributed via operating system updates and Google Play system updates.

No customer action is required unless the Android system trust store has been explicitly modified by device policy, enterprise management controls, or application-specific trust restrictions.

The IdenTrust Public Sector Root CA 1 is not included in the Google Chrome Root Store.

To ensure Google Chrome trusts certificates issued under this root CA, customers must ensure the root certificate is explicitly trusted at the operating system level in locations that Chrome consumes for local trust decisions.

Windows – required trust configuration

To ensure the root CA is trusted by Google Chrome on Windows, the IdenTrust Public Sector Root CA 1 must be imported into one of the following locations:

• Local Computer → Trusted Root Certification Authorities

  (Recommended for enterprise-managed systems)

or

• Current User → Trusted Root Certification Authorities

  (For user-level trust)

Certificates imported using the Windows Certificate Import Wizard into these locations (including via Group Policy) are trusted by Google Chrome.

Root certificates that exist only in the Windows Third-Party are not automatically trusted by Chrome unless explicitly imported as described above.

Mac OS – required trust configuration

To ensure the root CA is trusted by Google Chrome on macOS, the IdenTrust Public Sector Root CA 1 must be added to the macOS Keychain and explicitly trusted:

1. Import the certificate into the System Keychain (recommended) or Login Keychain

2. Open the certificate and set:

   • When using this certificate: Always Trust

     (or at minimum, SSL: Always Trust)

Once trusted at the system or user level, Google Chrome will honor the certificate as trusted.

Administrators can verify which platform certificates are trusted by Chrome by navigating to: chrome://certificate-manager/localcerts/platformcerts

For more information, see Google FAQ.

Third-party integrations represent the primary area requiring customer validation.

For any third-party applications or services that establish mTLS connections with Dedicated Instance UC applications, customers must:

• Validate that the third-party system trusts the IdenTrust Public Sector Root CA 1
• Work directly with the third-party vendor if trust store updates or CA changes are required

Customers can validate connectivity and trust for the new Public Root CA by accessing the following IdenTrust test certificate.

If this certificate opens successfully without trust warnings, the IdenTrust Public Sector Root CA 1 is already trusted in the environment.

If you have questions regarding this change, the Google Chrome browser policy, or certificate updates in Dedicated Instance, open a Service Request in Control Hub under UC application lifecyle.

UCM Cloud (UCMC) customers who own their domain and manage their own UC application certificate renewals and who have not delegated domain authority to Cisco for signing UC application certificates will be responsible for working directly with their chosen Public Certificate Authorities to address this change. 

These customers should also align with the applicable UC application product ( Cisco on-prem calling products and Cisco Expressway) recommendations regarding certificate usage and remediation related to the upcoming Public CA and browser policy changes. For more information, see Roles and Responsibilities. 

Cisco will continue to provide updates as UC application support for separate server and client certificates becomes available. Refer to this document for the latest updates.

Certificate EKU Changes: Actions Cisco On-premises Collaboration Customers MUST TAKE NOW