Check Webex SIP Certificates Before 2 November
Cisco plans to start enforcing a new trust policy on 2 November. Affected meeting gateways need a valid replacement certificate chain first.
Webex Meetings administrators using customer-managed secure SIP connections have a near-term certificate check to complete. In guidance published on 29 October, Cisco asks affected customers to finish certificate or chain changes before 2 November 2026, when enforcement of its revised trust policy is planned to begin.
The distinction matters: this is a planned change to which certificate authorities Webex trusts. It is not a report that every Webex meeting will fail on Monday. The rollout may be staged, and a connection is affected when its actual certificate chain depends on an authority covered by the change. Cisco does not give an exact enforcement start time in this guidance.
Which meeting paths need checking?
Cisco identifies two Webex Meetings integrations. Edge Audio dial-in and dial-out can stop working where they traverse an affected enterprise SIP connection. Collaboration Meeting Rooms, or CMR, can lose SIP-based video device joins through an affected secure SIP connection.
The customer-managed end may be a Cisco CUBE, Expressway-E or another session border controller. Check the primary system and its redundant or backup systems. A successful call through the main gateway does not establish that a failover gateway presents the same certificate chain.
Other meeting access methods do not depend on this same customer-managed SIP certificate path. Webex Calling is also a separate product: use its applicable guidance rather than applying this Meetings deadline indiscriminately across everything carrying the Webex name.
The chain matters, including cross-signing
The Webex guidance names four authorities to look for in the certification path:
- emSign Root TLS CA – G3
- emSign ECC Root CA – G3
- emSign Root CS CA – G3
- AAA Certificate Services, also described as the Comodo AAA Services root
AAA Certificate Services was not itself compromised. Cisco includes it because it cross-signed affected eMudhra intermediates. A Sectigo-issued customer certificate may therefore use an affected cross-signed path even though that customer certificate was not compromised. Treating every certificate under a familiar issuer name as either safe or stolen would miss this distinction.
There is a specific exclusion too: emSign Root CA – G1 is outside this Webex distrust change. Cisco says not to replace or remove certificates solely because they use G1. The task is to establish the deployed chain, not to delete everything whose name resembles a listed authority.
Inspect the system that actually presents the certificate
Start with the system serving the affected SIP integration. Record its real hostname and configured TLS port, then inspect its installed identity certificate and accompanying intermediate certificates. Cisco describes the Expressway-E certificate view and provides an OpenSSL-based inspection method for reachable SIP TLS listeners. Use the appropriate vendor procedure and an authorised management system for the deployment.
Inspect the complete returned chain, including certificate subjects and issuers. The guide specifically calls out a USERTrust RSA Certification Authority certificate issued by AAA Certificate Services as an example of an affected cross-signed path. Checking only the leaf certificate’s expiry date or its familiar commercial issuer is insufficient.
A failed probe needs investigation. An incorrect hostname or port, restricted access, or a listener requiring a client certificate can change the result. Cisco notes that an Expressway-E inspection may finish with an error while still showing the chain. Conversely, a timeout or no displayed certificate does not show that the integration is unaffected.
If an affected authority appears, prepare the replacement before enforcement. If none appears and the integration works, the guide indicates no immediate action from this check unless Cisco separately notified the organisation. A failing integration, an explicit Cisco notification or an inconclusive inspection should go to the Cisco partner or Technical Assistance Center for clarification.
Replacement is followed by a service test
Ask the certificate provider or reseller for an appropriate replacement certificate or an alternative chain ending at a root outside the four listed authorities. Where the product and provider support it, replacing the intermediate chain may be sufficient while retaining the existing identity certificate. That is a conditional option, not a universal instruction to reuse every certificate.
For the affected Sectigo cross-signed case, Cisco describes replacing the USERTrust certificate issued by AAA Certificate Services with an appropriate alternative chain. Do not simply remove the old intermediate and leave the service without a validated replacement. The identity certificate must still match the system’s configured SIP identity.
After installation, inspect the chain again and test the meeting paths that use it. For Edge Audio, that means the relevant meeting dial-in and callback or dial-out routes. For CMR, test SIP-based video joins. Include failover, then review TLS and certificate-validation errors if a path remains unavailable. A completed certificate installation is evidence of a change; successful service and failover checks provide the operational confirmation.
When escalating, Cisco asks for the organisation identifier, affected service and system, SIP hostname, chain details and relevant errors. Keep private keys out of the support material.
Why a cloud status row is not your change record
Cisco’s wider eMudhra advisory was last updated on 30 October at 21:52 GMT and remains version 1.5, Interim. It separates products still being investigated, impacted products with remediation guidance, software release targets and products confirmed not vulnerable. Those categories are different states, not interchangeable assurances.
In that version, the Webex Meetings cloud row says remediation is in progress and no customer action is required for that cloud work. The separately published Meetings guide nevertheless requires affected customer-managed SIP chains to be corrected before the planned trust change. Both statements can be true because Cisco’s cloud remediation and the certificate on a customer’s gateway are different responsibilities.
The broader table also contains future software targets, including dates in 2027. A target date having arrived does not establish that a release shipped or that an organisation deployed it. Follow the actual product-specific remediation route and its current release evidence. An entry about a product’s built-in trust handling should not substitute for inspecting a certificate installed for a particular integration.
The underlying incident concerns eight weak eMudhra issuing-certificate keys. Cisco describes the possibility of fraudulent certificates and says PSIRT is not aware of malicious use of the issue. That is its stated knowledge, not proof that interception has never occurred. The planned Webex change should be handled as a concrete trust and service-continuity task without inventing an observed customer outage or a new attack.
Application trust extends beyond browsers. Our October Node.js release review covers a separate runtime update path. Updating one application or trust store does not establish that a different deployed service has changed.
