Ação necessária: atualização de segurança da autoridade certificadora eMudhra para os gateways locais Webex Calling

Após o incidente de segurança da autoridade certificadora (CA) eMudhra de outubro de 2026, Webex Calling removeu a confiança em quatro CAs raiz. Se o tronco do Local Gateway baseado em certificado depender de uma dessas autoridades, substitua o certificado ou a cadeia afetada para manter a conectividade TLS segura. Se um tronco afetado estiver off-line, as chamadas PSTN de entrada e saída e as integrações locais que dependem dele podem não estar disponíveis.

Os certificados raiz afetados são:

EmSign Root TLS CA - 3G
eMsign ECC Root AC - 3G
EmSign Root CS CA - 3G
Serviços de certificados AAA (raiz do Comodo AAA Services)

Os serviços de certificação AAA não foram comprometidos. No entanto, ele assinou as CAs intermediárias afetadas do eMudhra, fornecendo um caminho de confiança alternativo para os certificados comprometidos.

Os clientes que usam troncos de gateway local (LGW) baseados em certificados, cujas cadeias de certificados dependem dessas autoridades, são afetados. Isso inclui certificados emitidos pela Sectigo que são vinculados aos Serviços de Certificados AAA por meio do UserTrust.

Webex Callingagora rejeita conexões TLS dos gateways locais afetados. As chamadas PSTN de entrada e saída e as integrações de chamadas locais que dependem desses gateways falharão.

Em um computador autorizado que possa acessar a porta SIP TLS do gateway, execute o comando aplicável. Substitua lgw.example.com e 5061 pelo nome do host do gateway e pela porta TLS. Se o acesso externo for restrito, execute o comando a partir de um host de gerenciamento interno autorizado.

Linux ou macOS:

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

Prompt de comando do Windows:

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

Antes de começar

Você precisa acessar o Control Hub com permissão para visualizar os troncos da organização.
O nome do host do gateway e a porta SIP TLS para cada gateway primário, redundante e de backup.
Acesso a um computador autorizado com OpenSSL que pode alcançar cada endpoint do gateway.

Identifique seus troncos de gateway local.

No Control Hub, vá para Serviços > PSTN e Roteamento > Configurações de gateway > Tronco.
Para clientes que usam o Cisco Calling Plan, a lista de troncos também está disponível em Service > Calling > Call Routing > Trunk.
Identifique troncos baseados em certificados e registre o endereço FQDN ou SRV configurado, o nome do host do gateway e a porta SIP TLS. Repita o procedimento para gateways redundantes e de backup.

Inspecione a cadeia de certificados de cada gateway.

Execute o comando OpenSSL aplicável. A saída exibe certificados apresentados pelo gateway local; ela não verifica de forma independente a cadeia completa em relação ao repositório Webex Calling confiável.
Um erro de handshake TLS ou uma verificação malsucedida do OpenSSL não provam que o gateway foi afetado por essa atualização de confiança.

Analise os assuntos e emissores do certificado.

Na seção Cadeia de certificados, revise o assunto (s:) e o emissor (i:) de cada certificado. Verifique o nome comum (CN) e todas as entradas da cadeia para ver as autoridades desconfiadas listadas acima.
Por exemplo, uma entrada com o assunto CN=UserTrust RSA Certification Authority e o emissor CN=AAA Certificate Services identifica um certificado emitido pelos Serviços de Certificados AAA.

Interprete os resultados da inspeção.

Resultado da cadeia de certificados	Status
Qualquer linha s: ou i: mostra os Serviços de Certificados AAA ou uma autoridade EmSign afetada	Afetado. Remedie agora.
Nenhuma das autoridades afetadas aparece e o porta-malas está on-line no Control Hub	Não afetado.
Nenhuma das autoridades afetadas aparece, mas o porta-malas está offline	Entre em contato com seu parceiro ou verifique Cisco TAC a lista de clientes afetados da Cisco.
A conexão expira ou nenhuma cadeia de certificados é retornada	Inconclusivo. Verifique o acesso da rede à porta TLS do gateway e tente novamente.

Um gateway é confirmado como não afetado somente quando nenhuma das raízes listadas aparece e o tronco está on-line no Control Hub.

Substitua uma cadeia de certificados afetada.

Entre em contato com seu provedor de certificados para obter um certificado substituto ou uma cadeia alternativa que termine em uma raiz confiável porWebex Calling. Em muitos casos, o certificado de gateway existente pode ser mantido e somente a cadeia intermediária substituída. Para implantações afetadas do Sectigo, isso pode envolver a substituição do certificado UserTrust com assinatura cruzada AAA por uma alternativa apropriada.
Instale a cadeia de certificados atualizada em seu gateway local e repita a verificação do certificado.
Confirme se o tronco está on-line no Control Hub e teste as chamadas de entrada e saída.

Verifique a conectividade do gateway local.

Repita a inspeção do OpenSSL e confirme que a cadeia de substituição não depende mais das autoridades desconfiadas.
No Control Hub, confirme se o tronco é exibido Online.
Teste as chamadas PSTN de entrada e saída e as integrações de chamadas locais que usam o tronco.
Repita a validação para gateways redundantes e de backup.

O que fazer a seguir

Se a cadeia parecer correta, mas o tronco permanecer offline, danificado ou desconhecido:

Verifique se o certificado é válido e está instalado corretamente.
Verifique a cadeia de CA intermediária completa e a identidade esperada do certificado.
Analise a conectividade TLS e os erros de validação do certificado no gateway.
Entre em contato com seu provedor de certificados, parceiro Cisco ou Cisco Technical Assistance Center (TAC) se o problema persistir. Ao entrar em contatoCisco Technical Assistance Center, forneça o ID da organização, detalhes do tronco afetado, nome do host do gateway, informações da cadeia de certificados e mensagens de erro TLS relevantes.

Informações relacionadas:

Cisco AI Assistant

Obrigado pelos seus comentários.

Pequena empresa

Empresa

Dispositivos

Soluções para

Recursos

Empresa