THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE FIELD NOTICE OR MATERIALS LINKED FROM THE FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.
| Affected Software Product | Affected Release | Affected Release Number | Comments |
|---|---|---|---|
| IOS XE Software | 16 | 16.1.1 | All Software Releases in 16.x.y are affected |
| IOS XE Software | 17 | 17.1.1 | All Software Releases in 17.x.y are affected |
| Defect ID | Headline |
| CSCws22989 | Certificate Segregation for CUBE TLS Profile-Client Trustpoint Support |
Effective June 2026, 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 only assert an Extended Key Usage (EKU) for Server Authentication (id-kp-serverAuth). As a result, certificates issued by Public Root CA with only Server Authentication EKU will not be valid for client authentication in mutual TLS (mTLS) setups.
To meet Chrome Root Program Policy requirements, effective June 2026, the Public Root CAs that are part of the Google Chrome Root Store will be restricted to Server Authentication EKU only, sunsetting the Client Authentication EKU from it. As a response, public CA servers will stop issuing Client Authentication EKU certifications from May 2026.
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.
The certificates that are used for mTLS connections in Cisco Unified Border Elements (CUBE) products 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 CUBE products and affecting proper functionality.
For more details, see Chrome Root Program Policy.
CUBE products can be affected by potential authentication issues and impacted functionality due to broken certificate validity caused by using Server Authentication EKU-only certificates provided by Public Root CAs.
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.
Note: The Cisco Integrated Services Router (ISR) 4000 Series platform is not supported by Cisco IOS XE Release 26.1.1. Consequently, the workarounds and solutions detailed in this Field Notice are not applicable to these devices. For more information, see End-of-Sale and End-of-Life Announcement for the Cisco ISR4200, ISR4300 and select ISR4400 Series Platform.
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 from an alternative root, which may not be included in the Chrome browser’s trust store. Coordinate with your 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.
This approach alleviates the need to upgrade server software to mitigate sunsetting of Client Authentication EKU enforced by the Google Chrome Root Program Policy.
The following table shows examples of Public Root CAs and EKU types:
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 May 2026 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 the policy sunsetting occurs.
For a certificate with maximum certificate validity, plan to renew certificates before March 15, 2026, after which Public CA-issued certificates will be valid only for 200 days. Public CA policy and implementation dates may vary. Check with your CA and plan your certificate renewal accordingly.
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.
Upgrade your servers after the solution mentioned below is available.
The following image shows the Client Authentication EKU depreciation timeline (subject to change):
To manage certificates for your CUBE product, see Cisco Unified Border Element Configuration Guide Through Cisco IOS XE 17.5.
Option 3: Evaluate and Migrate to Alternatives
Evaluate feasibility of transition to a private PKI, and then set up a private CA to issue single certificates with combined EKU (Server and Client certificates with the required 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. Using this approach will alleviate the need to upgrade server software to mitigate sunsetting of Client Authentication EKU enforced by the Google Chrome Root Policy.
Solution
The following product enhancements will be implemented in the fixed release that is described in the table in this section:
To segregate server and client certificates or to use the Ignore EKU option, upgrade to the fixed release of Cisco IOS XE Software as shown in the following table:
| Product | Affected Cisco IOS XE Software Release | First Fixed Release |
|---|---|---|
| CUBE | Earlier than IOS XE 26.1.1 | IOS XE 26.1.1 (future release) |
This issue also affects Cisco Expressway and Cisco Calling on-premises products. For information, see the following field notices:
| Version | Description | Section | Date |
| 1.0 | Initial Release | — | 2026-FEB-03 |
For further assistance or for more information about this field notice, contact the Cisco Technical Assistance Center (TAC) using one of the following methods:
To receive email updates about Field Notices (reliability and safety issues), Security Advisories (network security issues), and end-of-life announcements for specific Cisco products, set up a profile in My Notifications.
Unleash the Power of TAC's Virtual Assistance