Acción requerida: Actualización de seguridad de la autoridad de certificación eMudhra para Webex Calling Local Gateways

Tras el incidente de seguridad de la autoridad de certificación (CA) eMuDHRA de octubre de 2026, Webex Calling se eliminó la confianza en cuatro CA raíz. Si su enlace troncal Local Gateway basado en certificados depende de una de estas autoridades, reemplace el certificado o la cadena afectados para mantener una conectividad TLS segura. Si un tronco afectado está fuera de línea, las llamadas PSTN entrantes y salientes y las integraciones locales que dependen de él podrían no estar disponibles.

Los certificados raíz afectados son:

Emsign Root TLS CA - G3
Emsign ECC Root CA - G3
Emsign Root CS CA - G3
Servicios de certificación AAA (raíz de Comodo AAA Services)

Los servicios de certificación AAA no se comprometieron. Sin embargo, firmó las CA intermedias eMudhra afectadas, proporcionando una ruta de confianza alternativa a los certificados comprometidos.

Los clientes que utilizan troncales Local Gateway (LGW) basados en certificados cuyas cadenas de certificados dependen de estas autoridades se ven afectados. Esto incluye certificados emitidos por Sectigo que se encadenan a AAA Certificate Services a través de UserTrust.

Webex Callingahora rechaza las conexiones TLS de las puertas de enlace locales afectadas. Las llamadas PSTN entrantes y salientes, y las integraciones de llamadas locales que dependen de esas puertas de enlace, fallarán.

Desde un equipo autorizado que pueda llegar al puerto TLS SIP de la puerta de enlace, ejecute el comando correspondiente. Reemplace lgw.example.com y 5061 con el nombre de host de la puerta de enlace y el puerto TLS. Si el acceso externo está restringido, ejecute el comando desde un host de administración interna autorizado.

Linux o macOS:

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

Prompt de comando de Windows:

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

Antes de comenzar

Necesita acceso a Control Hub con permiso para ver los troncos de la organización.
El nombre de host de la puerta de enlace y el puerto TLS SIP para cada puerta de enlace principal, redundante y de backup.
Acceso a un equipo autorizado con OpenSSL que puede llegar a cada punto final de puerta de enlace.

Identifique sus troncales de puerta de enlace local.

En Control Hub, vaya a Servicios > PSTN y enrutamiento > Configuraciones de puerta de enlace > Troncal.
Para los clientes que utilizan Cisco Calling Plan, la lista troncal también está disponible en Servicio > Llamadas > Enrutamiento de llamadas > Troncal.
Identifique enlaces troncales basados en certificados y registre la dirección FQDN o SRV configurada, el nombre de host de la puerta de enlace y el puerto TLS SIP. Repita el procedimiento para puertas de enlace redundantes y de backup.

Inspeccione la cadena de certificados de cada puerta de enlace.

Ejecute el comando OpenSSL correspondiente. La salida muestra los certificados presentados por Local Gateway; no verifica independientemente la cadena completa con el almacén de Webex Calling confianza.
Un error de enlace TLS o una verificación fallida de OpenSSL no prueba que la puerta de enlace se vea afectada por esta actualización de confianza.

Revise los temas y emisores del certificado.

En la sección Cadena de certificados, revise los temas y emisores de cada certificado (i:). Verifique el nombre común (CN) y cada entrada de la cadena para las autoridades desconfiadas mencionadas anteriormente.
Por ejemplo, una entrada con el asunto CN=UserTrust RSA Certification Authority y el emisor CN=AAA Certificate Services identifica un certificado emitido por AAA Certificate Services.

Interprete los resultados de la inspección.

Resultado de la cadena de certificados	Estado
Cualquier línea s: o i: muestra los Servicios de Certificado AAA o una autoridad de eSign afectada	Afectado. Remedie ahora.
Ninguna de las autoridades afectadas aparece, y el maletero está en línea en Control Hub	No se ve afectado.
Ninguna de las autoridades afectadas aparece, pero el maletero está desconectado	Comuníquese con su socio o Cisco TAC para verificar la lista de clientes afectados de Cisco.
Se agota el tiempo de conexión o no se devuelve ninguna cadena de certificados	No concluyente. Verifique el acceso de red al puerto TLS de la puerta de enlace y vuelva a intentarlo.

Una puerta de enlace se confirma como no afectada solo cuando no aparece ninguna de las raíces enumeradas y el tronco está en línea en Control Hub.

Reemplace una cadena de certificados afectada.

Comuníquese con su proveedor de certificados para obtener un certificado de reemplazo o una cadena alternativa que termine en una raíz en la que confíe. Webex Calling En muchos casos, se puede conservar el certificado de puerta de enlace existente y solo se puede reemplazar la cadena intermedia. Para las implementaciones afectadas de Sectigo, esto puede implicar reemplazar el certificado UserTrust con firma cruzada AAA por una alternativa apropiada.
Instale la cadena de certificados actualizada en su puerta de enlace local y repita la comprobación del certificado.
Confirme que el baúl se muestra en línea en Control Hub y pruebe las llamadas entrantes y salientes.

Verifique la conectividad de la puerta de enlace local.

Repita la inspección OpenSSL y confirme que la cadena de reemplazo ya no depende de las autoridades desconfiadas.
En Control Hub, confirme que el baúl se muestre en línea.
Pruebe las llamadas PSTN entrantes y salientes y las integraciones de llamadas locales que utilizan el enlace troncal.
Repita la validación para backup y puertas de enlace redundantes.

Qué hacer a continuación

Si la cadena parece correcta pero el maletero permanece desconectado, deteriorado o desconocido:

Verifique que el certificado sea válido y esté instalado correctamente.
Verifique la cadena de CA intermedia completa y la identidad de certificado esperada.
Revise la conectividad TLS y los errores de validación de certificados en la puerta de enlace.
Comuníquese con su proveedor de certificados, partner de Cisco o Cisco Technical Assistance Center (TAC) si el problema persiste. Cuando se ponga en contactoCisco Technical Assistance Center, proporcione el ID de su organización, los detalles del enlace troncal afectado, el nombre de host de la puerta de enlace, la información de la cadena de certificados y los mensajes de error TLS relevantes.

Información relacionada:

Cisco AI Assistant

Gracias por sus comentarios.

Pequeñas empresas

Enterprise

Dispositivos

Soluciones para

Recursos

Company