Field Notice: FN74392 - Cisco Identity Services Engine: Impact on Secure Communications from Public CA Client Authentication EKU Changes Starting in May 2026 - Workaround Provided

Beginning in May 2026, many public certificate authorities (CAs) will stop issuing Transport Layer Security (TLS) certificates that include the Client Authentication Extended Key Usage (EKU). Newly issued certificates will typically include Server Authentication EKU only.

As a result, if certificates issued by a public CA are renewed under the updated CA policies and then deployed in Cisco Identity Services Engine (ISE), services where Client Authentication EKU is required will fail. The specific services being impacted are: pxGrid, ISE Messaging Service (IMS), and TC-NAC (Threat Centric Network Access Control). 

Publicly trusted TLS certificates are issued by CAs that must comply with industry policies governing certificate issuance and usage. 

The Chrome Root Program Policy, operated by Google, defines requirements that CAs must follow for their certificates to be trusted by the Google Chrome browser. These requirements influence how publicly trusted certificates are issued across the industry. As part of evolving security practices, the Chrome Root Program is introducing stricter guidance around certificate usage.

Many public CAs are therefore moving away from issuing certificates that include Client Authentication EKU and are transitioning toward issuing certificates intended only for server authentication. As a result, newly issued certificates from many public CAs are expected to include Server Authentication EKU only. 

Services Impacted on Cisco ISE

Cisco ISE uses TLS certificates for several services. Services listed in the following table expect certificates that include both Server Authentication EKU and Client Authentication EKU. As a result, if certificates that are issued by a public CA are renewed under the updated CA policies and then deployed in Cisco ISE, affected services may fail where Client Authentication EKU is still required. 

This notice applies to customers who use public CA-issued certificates for the services listed in the table, unless their private or enterprise CA enforces similar Client Authentication EKU restrictions.

Note: The solution in this Field Notice is limited to the pxGrid and IMS services. Cisco ISE may also act as a TLS client for other services (TC-NAC, LDAPS, Secure Syslog, Radius DTLS). For additional details, see the Prepare Identity Services Engine for Extended Key Usage Restrictions in Certificates Issued by Public Certification Authorities TechNote.

After deploying Server Authentication EKU-only certificates, customers will observe certificate import or bind failures in the Cisco ISE GUI when attempting to upload pxGrid or IMS certificates that do not meet the current EKU requirements for the selected service.

The following image shows an example of the error message that will display.  

Services that rely on these certificates may become partially or fully unavailable until the required actions that are described in this notice are completed. 

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. 

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.

This approach alleviates the need to upgrade server software to mitigate sunsetting of Client Authentication EKU enforced by the Chrome Root Program Policy.

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 are 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. 

Public CA policy and implementation dates may vary by vendor. Check with the CA and plan certificate renewal accordingly. 

Option 3: Migrate to private PKI

Evaluate the feasibility of transitioning to a private Public Key Infrastructure (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 urgency to patch the Cisco ISE system software to mitigate sunsetting of Client Authentication EKU enforced by the Google Chrome Root Policy.

Solution

Upgrade Cisco ISE system software to a patch release that introduces updated certificate handling for certificates issued under the new CA policies. The following patches will be released starting mid-April 2026: 

After upgrading Cisco ISE, do the following:

pxGrid Certificate (ISE)

Cisco ISE will allow the import or bind of pxGrid certificates containing Server Authentication EKU only.

Note: Verify the certificate type used by any external pxGrid clients. Upon renewal, public CA-signed certificates may no longer include Client Authentication EKU. External pxGrid client integrations must include the Client Authentication EKU when communicating with Cisco ISE or the connection will be rejected resulting in a non-functional integration.

IMS Certificate

For Cisco ISE releases 3.1, 3.2, and 3.3, there is no change in behavior after installing the patch. IMS will continue to require a certificate with both Client and Server EKU. Customers should plan to use an ISE Internal CA certificate after the current certificate expires.

To renew the IMS certificate with a Cisco ISE internal CA certificate, complete the following steps:

1. Choose Administration > System > Certificates > Certificate Management > Certificate Signing Request.
2. Choose Generate Certificate Signing Request (CSR).
3. Under Usage, choose ISE Messaging Service.
4. Choose all nodes in the deployment.
5. Click Generate ISE Messaging Service Certificate.

No service restart is required.

For Cisco ISE releases 3.4 and 3.5, after installing the patch, IMS will support public CA certificates that contain Server Authentication EKU only. However, because IMS is used only for internal Cisco ISE communication, Cisco recommends using the Cisco ISE internal CA certificate when the certificate is renewed.