Field Notice: FN74404 - Cisco Secure Network Analytics: Impact on Secure Communications from Public CA Client Authentication EKU Changes Starting 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. 

Cisco Secure Network Analytics (SNA) requires both Server and Client Authentication EKU to provide mutual TLS (mTLS) for connections between appliances within a Cisco SNA cluster. If certificates that are issued by a public CA are renewed under the updated CA policies and then deployed in a Cisco SNA cluster, inter-appliance communication within the cluster will fail.

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

The Chrome Root Program, 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 SNA 

Each appliance within a Cisco SNA cluster is initially installed with a unique, self-signed appliance identity certificate. Communication between appliances is then authenticated using x.509v3 certificates. Customers who are using self-signed certificates for appliance authentication will be unaffected by these changes. 

Customers who are using an internal or private Public Key Infrastructure (PKI) to generate certificates (which incorporate both the Server and Client Authentication EKU required for mTLS communications between Cisco SNA appliances) will be unaffected by these changes. 

Customers who are using public CAs to generate identity certificates (in replacement of Cisco SNA appliance identity certificates) will be impacted by these changes. Current certificates that were issued by public CAs will still be accepted, but upon expiration, customers will not be able to request public certificates with both Server and Client Authentication EKU included. Public CAs will also not honor Cisco SNA certificate signing requests (CSRs) for Client Authentication EKU. 

Additionally, customers who have integrated Cisco SNA with Cisco ISE may also be impacted because this integration requires using secondary appliance identity certificates. Customers who opted to use a public CA for those secondary appliance certificates will be impacted. Customers who used the internal Cisco ISE CA or a private CA to provide those certificates will remain unaffected. 

The primary symptom will be the loss of connectivity between Cisco SNA appliances in a cluster deployment model.

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: Migrate to Private PKI  

Evaluate the feasibility of transitioning 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) for use with Cisco SNA. 

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. This short-term action provides time to review all available options and determine a long-term solution for your environment. 

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

Option 3: 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 these are added to the Cisco SNA trust store. It is also important that any browsers used to access Cisco SNA also trust these certificates..

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