Action requise : mise à jour de sécurité de l'autorité de certification eMudhra pour les passerelles locales Webex Calling

À la suite de l'incident de sécurité de l'autorité de certification (CA) eMudhra en octobre 2026, la confiance envers quatre autorités de certification racines Webex Calling a été supprimée. Si le tronc de votre passerelle locale basé sur des certificats dépend de l'une de ces autorités, remplacez le certificat ou la chaîne concernés pour maintenir une connectivité TLS sécurisée. Si un tronçon concerné est hors ligne, les appels RTPC entrants et sortants et les intégrations sur site qui en dépendent peuvent ne pas être disponibles.

Les certificats racines concernés sont les suivants :

eSign Root TLS CA - 3G
eSign ECC Root CA - G3
eSign Root SC CA - G3
Services de certificats AAA (racine des services Comodo AAA)

AAA Certificate Services n'a pas été compromis. Cependant, elle a signé de manière croisée les autorités de certification intermédiaires eMudhra concernées, fournissant ainsi une autre voie de confiance vers les certificats compromis.

Les clients qui utilisent des troncs de passerelle locale basée sur des certificats (LGW) dont les chaînes de certificats dépendent de ces autorités sont concernés. Cela inclut les certificats émis par Sectigo qui sont liés à AAA Certificate Services via UserTrust.

Webex Callingrejette désormais les connexions TLS provenant des passerelles locales concernées. Les appels PSTN entrants et sortants, ainsi que les intégrations d'appels sur site qui reposent sur ces passerelles, échoueront.

Depuis un ordinateur autorisé pouvant accéder au port SIP TLS de la passerelle, exécutez la commande appropriée. Remplacez lgw.example.com et 5061 par le nom d'hôte de la passerelle et le port TLS. Si l'accès externe est restreint, exécutez la commande depuis un hôte de gestion interne autorisé.

Linux ou macOS :

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

Invite de commandes Windows :

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

Avant de commencer

Vous devez accéder à Control Hub pour pouvoir consulter les troncs de l'organisation.
Le nom d'hôte de la passerelle et le port SIP TLS pour chaque passerelle principale, redondante et de secours.
Accès à un ordinateur autorisé avec OpenSSL capable d'atteindre chaque point de terminaison de passerelle.

Identifiez les troncs de votre passerelle locale.

Dans Control Hub, accédez à Services > PSTN et routage > Configurations des passerelles > Trunk.
Pour les clients utilisant le plan d'appel Cisco, la liste des lignes téléphoniques est également disponible sur Service > Appels > Routage des appels > Trunk.
Identifiez les tronks basés sur des certificats et enregistrez l'adresse FQDN ou SRV configurés, le nom d'hôte de la passerelle et le port SIP TLS. Répétez l'opération pour les passerelles redondantes et de secours.

Inspectez la chaîne de certificats de chaque passerelle.

Exécutez la commande OpenSSL applicable. La sortie affiche les certificats présentés par la passerelle locale ; elle ne vérifie pas la chaîne complète de manière indépendante par rapport au Webex Calling Trust Store.
Une erreur de prise de contact TLS ou un échec de la vérification d'OpenSSL ne prouvent pas que la passerelle est affectée par cette mise à jour de confiance.

Passez en revue les sujets et les émetteurs des certificats.

Dans la section Chaîne de certificats, passez en revue le sujet (s) et l'émetteur (i :) de chaque certificat. Vérifiez le nom commun (CN) et chaque entrée de chaîne pour connaître les autorités méfiantes répertoriées ci-dessus.
Par exemple, une entrée dont le sujet est CN=UserTrust RSA Certification Authority et l'émetteur CN=AAA Certificate Services identifie un certificat émis par AAA Certificate Services.

Interprétez les résultats de l'inspection.

Résultat de la chaîne de certificats	Statut
N'importe quelle ligne s : ou i : indique les services de certification AAA ou une autorité de signature électronique concernée	Affectée. Corrigez tout de suite.
Aucune des autorités concernées n'apparaît et le coffre est en ligne sur Control Hub	Non affectée.
Aucune des autorités concernées n'apparaît, mais le coffre est hors ligne	Contactez votre partenaire ou Cisco TAC consultez la liste des clients concernés de Cisco.
La connexion expire ou aucune chaîne de certificats n'est renvoyée	Peu concluant. Vérifiez l'accès réseau au port TLS de la passerelle et réessayez.

Une passerelle est confirmée comme n'étant pas affectée uniquement lorsqu'aucune des racines répertoriées n'apparaît et que le tronc est en ligne sur Control Hub.

Remplacez la chaîne de certificats concernée.

Contactez votre fournisseur de certificats pour obtenir un certificat de remplacement ou une chaîne alternative qui se termine à une racine approuvée parWebex Calling. Dans de nombreux cas, le certificat de passerelle existant peut être conservé et seule la chaîne intermédiaire peut être remplacée. Pour les déploiements Sectigo concernés, cela peut impliquer de remplacer le certificat UserTrust signé AAA par une alternative appropriée.
Installez la chaîne de certificats mise à jour sur votre passerelle locale et recommencez la vérification des certificats.
Vérifiez que le coffre est en ligne dans Control Hub et testez les appels entrants et sortants.

Vérifiez la connectivité de la passerelle locale.

Répétez l'inspection OpenSSL et vérifiez que la chaîne de remplacement ne dépend plus des autorités qui se méfient.
Dans Control Hub, vérifiez que le coffre indique Online.
Testez les appels RTPC entrants et sortants et les intégrations d'appels sur site qui utilisent le trunk.
Répétez la validation pour les passerelles de sauvegarde et redondantes.

Que faire ensuite

Si la chaîne semble correcte mais que le coffre reste hors ligne, en état d'ébriété ou inconnu :

Vérifiez que le certificat est valide et correctement installé.
Vérifiez l'ensemble de la chaîne de certification intermédiaire et l'identité de certificat attendue.
Passez en revue les erreurs de connectivité TLS et de validation des certificats sur la passerelle.
Contactez votre fournisseur de certificat, votre partenaire Cisco ou Cisco Technical Assistance Center (TAC) si le problème persiste. Lorsque vous contactezCisco Technical Assistance Center, fournissez l'identifiant de votre organisation, les informations relatives au tronc concerné, le nom d'hôte de la passerelle, les informations de la chaîne de certificats et les messages d'erreur TLS pertinents.

Informations connexes :

Cisco AI Assistant

Merci pour votre commentaire.

Petite entreprise

Enterprise

Périphériques

Solutions pour le

Ressources

Société