Action required: eMudhra certificate authority security update for Webex Calling Local Gateways

Following the October 2026 eMudhra certificate authority (CA) security incident, Webex Calling removed trust in four root CAs. If your certificate-based Local Gateway trunk depends on one of these authorities, replace the affected certificate or chain to maintain secure TLS connectivity. If an affected trunk is offline, inbound, and outbound PSTN calls and on-premises integrations that depend on it might be unavailable.

The affected root certificates are:

emSign Root TLS CA - G3
emSign ECC Root CA - G3
emSign Root CS CA - G3
AAA Certificate Services (Comodo AAA Services root)

AAA Certificate Services was not compromised. However, it cross-signed the affected eMudhra intermediate CAs, providing an alternate trust path to the compromised certificates.

Customers using certificate-based Local Gateway (LGW) trunks whose certificate chains depend on these authorities are impacted. This includes Sectigo-issued certificates that chain to AAA Certificate Services through USERTrust.

Webex Calling now rejects TLS connections from affected Local Gateways. Inbound and outbound PSTN calling, and on-premises calling integrations that rely on those gateways, will fail.

From an authorized computer that can reach the gateway’s SIP TLS port, run the applicable command. Replace lgw.example.com and 5061 with the gateway hostname and TLS port. If external access is restricted, run the command from an authorized internal management host.

Linux or macOS:

openssl s_client -connect lgw.example.com:5061 -showcerts </dev/null

Windows Command Prompt:

openssl s_client -connect lgw.example.com:5061 -showcerts <NUL

Before you begin

You require access to Control Hub with permission to view the organization’s trunks.
The gateway hostname and SIP TLS port for each primary, redundant, and backup gateway.
Access to an authorized computer with OpenSSL that can reach each gateway endpoint.

Identify your Local Gateway trunks.

In Control Hub, go to Services > PSTN & Routing > Gateway configurations > Trunk .
For customers using the Cisco Calling Plan, the trunk list is also available at Service > Calling > Call Routing > Trunk.
Identify certificate-based trunks and record the configured FQDN or SRV address, gateway hostname, and SIP TLS port. Repeat for redundant and backup gateways.

Inspect each gateway’s certificate chain.

Run the applicable OpenSSL command. The output displays certificates presented by the Local Gateway; it doesn’t independently verify the complete chain against the Webex Calling trust store.
A TLS handshake error or unsuccessful OpenSSL verification doesn’t prove that the gateway is affected by this trust update.

Review the certificate subjects and issuers.

In the Certificate chain section, review each certificate’s subject (s:) and issuer (i:). Check the common name (CN) and every chain entry for the distrusted authorities listed above.
For example, an entry with subject CN=USERTrust RSA Certification Authority and issuer CN=AAA Certificate Services identifies a certificate issued by AAA Certificate Services.

Interpret the inspection results.

Certificate chain result	Status
Any s: or i: line shows AAA Certificate Services or an affected emSign authority	Affected. Remediate now.
None of the affected authorities appears, and the trunk is Online in Control Hub	Not affected.
None of the affected authorities appears, but the trunk is Offline	Contact your partner or Cisco TAC to verify against Cisco's affected-customer list.
Connection times out or no certificate chain is returned	Inconclusive. Verify network access to the gateway's TLS port and retry.

A gateway is confirmed as not affected only when none of the listed roots appear and the trunk is Online in Control Hub.

Replace an affected certificate chain.

Contact your certificate provider to obtain a replacement certificate or alternative chain that terminates at a root trusted by Webex Calling. In many cases, the existing gateway certificate can be retained and only the intermediate chain replaced. For affected Sectigo deployments, this may involve replacing the AAA-cross-signed USERTrust certificate with an appropriate alternative.
Install the updated certificate chain on your Local Gateway and repeat the certificate check.
Confirm the trunk shows Online in Control Hub and test inbound and outbound calls.

Verify Local Gateway connectivity.

Repeat the OpenSSL inspection and confirm that the replacement chain no longer depends on the distrusted authorities.
In Control Hub, confirm that the trunk shows Online.
Test inbound and outbound PSTN calls and on-premises calling integrations that use the trunk.
Repeat validation for backup and redundant gateways.

What to do next

If the chain appears correct but the trunk remains Offline, Impaired, or Unknown:

Verify that the certificate is valid and installed correctly.
Check the complete intermediate CA chain and the expected certificate identity.
Review TLS connectivity and certificate validation errors on the gateway.
Contact your certificate provider, Cisco partner, or Cisco Technical Assistance Center (TAC) if the issue persists. When you contact Cisco Technical Assistance Center, provide your organization ID, affected trunk details, gateway hostname, certificate chain information, and relevant TLS error messages.

Related information:

Cisco AI Assistant

Thanks for your feedback.

Small Business

Enterprise

Devices

Solutions For

Resources

Company