In this article
dropdown icon
What may be affected
    Certificate Authorities
Check and replace affected certificates or chains
Related Information
October 29, 2026 | 26 view(s) | 0 people thought this was helpful
Check and fix certificates affected by the eMudhra security update for Webex Meetings
list-menuIn this article
list-menuFeedback?

Cisco is removing trust in certain root CAs used to validate secure SIP connections, following the October 2026 eMudhra certificate authority (CA) security incident. Enforcement for affected Webex Meetings SIP integrations is planned to begin November 2, 2026. The rollout may take place in stages. Plan to complete your changes before November 2. Customers whose certificate chains depend on the distrusted authorities must replace the affected certificate or chain. Otherwise, the affected secure SIP connection will fail TLS authentication, when the updated trust policy is enforced for that connection.

What may be affected

Integrations

  • Webex Meetings Edge Audio: Meeting dial-in and dial-out through affected enterprise SIP connections will stop working when enforcement reaches those connections.

  • Collaboration Meeting Rooms (CMR): SIP-based video device joins through affected secure SIP connections will fail when enforcement reaches those connections.

  • Customer-managed infrastructure may include Cisco CUBE, Expressway-E, and other Session Border Controllers (SBCs). Review both primary and redundant systems.

These changes target SIP integrations using affected certificate chains; other meeting access methods do not depend on the same customer-managed SIP certificate path.

Certificate Authorities

Check for certificate chains that depend on any of the following authorities:

  • 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, but it cross-signed affected eMudhra intermediates and is included in this security response. Some Sectigo-issued certificates may use an AAA-cross-signed certification path even though the Sectigo customer certificates themselves were not compromised.

emSign Root CA - G1 is not included in this distrust change. Do not replace or remove certificates solely because they use G1.

Check and replace affected certificates or chains

1

Identify the CUBE, Expressway-E, or SBC used for the affected Edge Audio or SIP-based meeting integration. Record the actual hostname and configured SIP TLS port. Then, inspect the TLS identity certificate installed on that system and any accompanying intermediate CA certificates.

On Expressway-E, the installed server certificate can be viewed under Maintenance > Security > Server certificate. For CUBE and other SBCs, use the applicable vendor certificate inspection procedure.

Repeat for backup and redundant systems.

2

From a computer with OpenSSL installed and network access to the SIP TLS listener, run the relevant example:

  • Linux or macOS: 

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

  • Windows Command Prompt: 

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

Replace the example hostname and port with your actual SIP TLS endpoint; the port may differ by deployment. If inbound TLS access is restricted, run the check from an authorized management system.

On Expressway-E, the SIP TLS port used with Webex may require a client certificate. The command may then end with an error, but the certificate chain is still shown.

Review the certificate chain entries, including the subject (s:) and issuer (i:). Look for any of the four affected CA names, including a USERTrust RSA Certification Authority certificate issued by AAA Certificate Services.

Example of an affected cross-signed chain entry:

  • s: CN=USERTrust RSA Certification Authority

  • i: CN=AAA Certificate Services

3

Interpret the findings:

  • Affected CA found: Treat the chain as affected and update it before enforcement.

  • No affected CA shown and the SIP integration is working: No immediate action is indicated by this check unless Cisco separately notified your organization of an affected dependency.

  • No affected CA shown but Cisco notified your organization, or the SIP integration is failing: Contact your Cisco partner or Cisco TAC for help identifying the full certification path and affected connection.

  • No certificate displayed or the connection times out: Confirm the correct hostname, port, access controls, and inspection method.

4

Contact your certificate provider or reseller for a replacement certificate or alternative certificate chain ending at a root not listed above. Ask the provider to confirm that the replacement chain is appropriate for the Webex SIP integration.

  • Where supported, retain the existing identity certificate and replace only the intermediate chain. For affected Sectigo deployments, replace the USERTrust certificate issued by AAA Certificate Services with an appropriate alternative chain from Sectigo or your provider. Never remove it without installing and validating its replacement.

  • Install the certificate or chain on each affected CUBE, Expressway-E, or SBC, following that product’s configuration instructions. Ensure the installed identity certificate remains valid for the system’s configured SIP identity.

Inspect the installed chain again to verify that it no longer depends on the distrusted authorities.

5

Validate the meeting connectivity:

  • For Edge Audio, test the meeting dial-in and callback/dial-out routes that traverse the affected enterprise SIP connection.

  • For CMR, test SIP-based video device joins through the affected infrastructure.

  • Check both primary and failover paths. Review TLS errors and certificate validation failures if a connection remains unavailable.

If certificate or SIP connectivity problems persist, contact your Cisco partner or Cisco Technical Assistance Center (TAC). Provide your Webex Organization ID, the impacted service, the affected system and SIP hostname, the certificate chain details, and any TLS or SIP error messages. Do not share private keys.

Was this article helpful?
Was this article helpful?
PricingWebex AppMeetingsCallingMessagingScreen Sharing
Webex SuiteCallingMeetingsMessagingSlidoWebinarsEventsContact CenterCPaaSSecurityControl Hub
HeadsetsCamerasDesk SeriesRoom SeriesBoard SeriesPhone SeriesAccessories
EducationHealthcareGovernmentFinanceSports & EntertainmentFrontlineNonprofitsStartupsHybrid Work
DownloadsJoin a Test MeetingOnline ClassesIntegrationsAccessibilityInclusivityLive & On-Demand WebinarsWebex CommunityWebex DevelopersNews & Innovations
CiscoContact SupportContact SalesWebex BlogWebex Thought LeadershipWebex Merch StoreCareers
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
Terms & ConditionsPrivacy StatementCookiesTrademarks
©2026 Cisco and/or its affiliates. All rights reserved.
Terms & ConditionsPrivacy StatementCookiesTrademarks