Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided

Effective March 2027, the Chrome Root Program Policy will restrict root certificate authority (CA) certificates that are included in the Chrome Root Store, phasing out multi-purpose roots to align all public-key infrastructure (PKI) hierarchies to serve only TLS server authentication use cases.

This constraint includes root CAs that assert an Extended Key Usage (EKU) only for server authentication (id-kp-serverAuth). As a result, certificates issued by a public root CA with only Server Authentication EKU will not be valid for client authentication in mutual TLS (mTLS) setups.

Note: The effective date of the Chrome Root Program Policy is subject to change. For the most up-to-date information, see the Chrome Root Program Policy.

To meet the Chrome Root Program Policy requirement, effective March 2027, public root CAs that are part of the Chrome Root Store will be restricted to Server Authentication EKU only, effectively sunsetting the Client Authentication EKU from the store. This date might change, and timelines will be decided by the CAs.

Certificates must include only Server Authentication EKU to maintain trust from the Google Chrome browser. Including the Client Authentication EKU in these certificates will be prohibited.

Although certain public root CAs continue to issue certificates containing the Client Authentication EKU, they will eventually be removed from the Chrome Root Store.

Certificates that are used for mTLS connections in Cisco Expressway are expected to include both Server and Client Authentication EKUs. Customers could choose to have these certificates from public CA providers.

Server Authentication EKU-only certificates that are provided by public root CAs can break certificate validity, leading to potential authentication issues in Cisco Expressway and affecting proper functionality.

For more details, see the Chrome Root Program Policy.

Cisco Expressway can be affected by potential authentication issues and impacted functionality due to broken certificate validity that is caused by using Server Authentication EKU-only certificates provided by public root CAs. The public CA-signed certificate with Client Authentication EKU that is currently used for mTLS connections in Cisco Expressway is the Expressway Certificate.

This certificate is used for different mTLS connections, as shown in the following examples:

• SIP B2B call over mTLS (Expressway E becomes client or server on mTLS connection, depending on session-initiated site).
• SIP IMP Federation over mTLS (Expressway E becomes client or server on mTLS connection, depending on session-initiated site).
• UC Traversal Zone (Expressway C presents Client Authentication EKU).
• Traversal Zone with mTLS configuration (Expressway C presents Client Authentication EKU).
• SIP Neighbor Zone with mTLS configuration (Expressway becomes client or server on mTLS connection, depending on session-initiated site), including Cisco Unified Communications Manager (Unified CM), Cisco Unity, Cisco Unified Border Element (CUBE), and Cisco Meeting Server (CMS).
• Connection to Cisco Cloud (Mobile and Remote Access (MRA) Onboarding, with Expressway initiating the connection to Cisco Cloud and presenting Client Authentication EKU).

Before considering workaround and solution options, audit current certificates. Prepare an inventory of all public TLS certificates to identify which certificates contain the Client Authentication EKU. It is recommended that customers take a backup of their Cisco Expressway instance or manually copy the signed certificate and Private key.

Workaround

Administrators can choose from one of the following workaround options.

Option 1: Switch to public root CAs that provide combined EKU certificates.

Some public root CAs, such as DigiCert and IdenTrust, issue certificates with combined EKU types (server and client certificates) from an alternative root, which may not be included in the Chrome Root Store. Coordinate with the CA provider to check the availability of such certificates, and, before deploying them, ensure that both the server presenting the certificate and the clients consuming it trust the corresponding root CA.

The following table, which shows examples of public root CAs and EKU types, is not an exhaustive list and is for illustrative purposes only.

CA Vendor	EKU Type	Root CA	Issuing/Sub CA
IdenTrust	clientAuth + serverAuth	IdenTrust Public Sector Root CA 1	IdenTrust Public Sector Server CA 1
IdenTrust	clientAuth	IdenTrust Public Sector Root CA 1	TrustID RSA ClientAuth CA 2
IdenTrust	serverAuth (browser trusted)	IdenTrust Commercial Root CA 1	HydrantID Server CA O1
DigiCert	clientAuth + serverAuth	DigiCert Assured ID Root G2	DigiCert Assured ID CA G2
DigiCert	clientAuth	DigiCert Assured ID Root G2	DigiCert Assured ID Client CA G2
DigiCert	serverAuth (browser trusted)	DigiCert Global Root G2	DigiCert Global G2 TLS RSA SHA256

 

Option 2: Renew current certificates to extend validity.

Certificates that were issued by public root CAs before the sunsetting of Client Authentication EKU and that have both Server and Client Authentication EKU will continue to be honored until their term expires. However, it is best to renew combined EKU certificates before policy sunsetting occurs.

To maximize certificate validity, renew certificates before March 15, 2026, when public CAs will reduce maximum validity to 200 days. Note that CA policies vary. Some may implement this change earlier, reducing validity to 200 and 100 days. Work with CA providers to find the appropriate date and path.

For customers using Let's Encrypt Certificates: Currently, Expressway uses a classic ACME profile and cannot be modified by users. This classic ACME profile is presently used for requesting certificates that include both Server and Client Authentication EKUs. Starting February 11, 2026, certificate requests using this profile will no longer include the Client Authentication EKU in certificates generated by Let's Encrypt.

• Note: Customers that are using Let's Encrypt certificates with the classic ACME profile should renew before February 11, 2026, ideally as close to that date as possible to maximize validity. For more information, see Ending TLS Client Authentication Certificate Support in 2026 - Let's Encrypt.
• Customers should also disable the ACME automated scheduler to prevent certificates from being automatically renewed after February 11, 2026. This action will help avoid certificates being inadvertently overwritten with versions that contain only the Server Authentication EKU.

Note: Some public CAs have stopped issuing combined EKU certificates and may not provide one by default. To generate a certificate with a combined EKU, work with public CAs, which may provide special profiles.

The following image shows the Client Authentication EKU depreciation timeline, which is subject to change. For the most recent information, check with the specific CA.

                

After the solution becomes available, upgrade servers. For more information, see the Solution section of this Field Notice. Follow the steps in the relevant Cisco Expressway Admin Guide to manage Expressway certificates:

• Cisco Expressway Certificate Creation and Use Deployment Guide (X14.0)
• Cisco Expressway Certificate Creation and Use Deployment Guide (X15.0)

 

Option 3: Evaluate and Migrate to Alternatives (for Expressway C only; not applicable for Expressway E).

Evaluate the feasibility of transitioning to a private PKI and then set up a private CA to issue single certificates with combined EKUs.

Before issuing or deploying a certificate, ensure that both the server presenting the certificate and all clients consuming it trust the corresponding root CA.

Solution

The following product enhancements will be implemented in the fixed release that is described in the table in this section:

• Segregation of client and server certificates: This will enable support for two separate certificates on the same interface (such as Expressway certificates with distinct Server Authentication EKU and Client Authentication EKU) to facilitate mTLS connections.
• Options for administrators to disable Client Authentication EKU check: This will allow Cisco Expressway to ignore EKU from remote peers (client) that are requesting a connection with Server Authentication EKU-only certificates. In the absence of a Client Authentication EKU certificate, this option will also allow Expressway to (re)use the Server Authentication EKU-only certificate as a Client certificate. Note: The remote peer will also have to support a similar Ignore Client Authentication EKU model.

To segregate server and client certificates or to use the Ignore EKU option, upgrade to a fixed release as shown in the following table:

Note: Both Cisco Expressway E and Expressway C must be upgraded to the same version.

The following field notices address other Cisco Collaboration products that are affected by this issue:

• FN74345: Cisco Calling On-Premises products
• FN74350: Cisco Unified Border Element (CUBE)

For more information about this issue, see the following:

• Public CA certificate changes impacting Dedicated Instance
• Blog: Changes to TLS clientAuth Certificates - Ensuring You're Not Impacted
• Certificate EKU Changes: Actions Cisco On-premises Collaboration Customers MUST TAK NOW