Danke für Ihr Feedback.
Feedback?Nach dem Sicherheitsvorfall der eMudhra Certificate Authority (CA) vom Oktober 2026 wurde das Vertrauen in vier Stammzertifizierungsstellen Webex Calling aufgehoben. Wenn Ihr zertifikatsbasierter Local Gateway-Trunk von einer dieser Behörden abhängt, ersetzen Sie das betroffene Zertifikat oder die betroffene Kette, um eine sichere TLS-Konnektivität aufrechtzuerhalten. Wenn ein betroffener Trunk offline ist, sind eingehende und ausgehende PSTN-Anrufe und lokale Integrationen, die davon abhängen, möglicherweise nicht verfügbar.
Die betroffenen Stammzertifikate sind:
-
EmSign Root TLS CA — 3G
-
EmSign ECC Root AC — 3G
-
EmSign Root SC AC — 3G
-
AAA-Zertifikatsdienste (Comodo AAA-Dienste root)
Die AAA-Zertifikatsdienste wurden nicht kompromittiert. Es hat jedoch die betroffenen zwischengeschalteten eMudhra-Zertifizierungsstellen gegensigniert, wodurch ein alternativer Vertrauenspfad zu den kompromittierten Zertifikaten geschaffen wurde.
Kunden, die zertifikatsbasierte Local Gateway (LGW) -Trunks verwenden, deren Zertifikatsketten von diesen Behörden abhängen, sind betroffen. Dazu gehören von Sectigo ausgestellte Zertifikate, die über UserTrust mit den AAA-Zertifikatsdiensten verbunden sind.
Webex Callinglehnt jetzt TLS-Verbindungen von betroffenen Local Gateways ab. Eingehende und ausgehende PSTN-Anrufe und Integrationen für lokale Anrufe, die auf diesen Gateways basieren, werden fehlschlagen.
Führen Sie auf einem autorisierten Computer, der den SIP-TLS-Port des Gateways erreichen kann, den entsprechenden Befehl aus. Ersetzen Sie lgw.example.com und 5061 durch den Gateway-Hostnamen und den TLS-Port. Wenn der externe Zugriff eingeschränkt ist, führen Sie den Befehl von einem autorisierten internen Management-Host aus.
Linux oder macOS:
openssl s_client -connect lgw.example.com:5061 -showcerts </dev/nullWindows-Eingabeaufforderung:
openssl s_client -connect lgw.example.com:5061 -showcerts <NULVorbereitungen
- Sie benötigen Zugriff auf Control Hub mit der Erlaubnis, die Trunks der Organisation einzusehen.
- Der Gateway-Hostname und der SIP-TLS-Port für jedes primäre, redundante und Backup-Gateway.
- Zugriff auf einen autorisierten Computer mit OpenSSL, der jeden Gateway-Endpunkt erreichen kann.
| 1 |
Identifizieren Sie Ihre Local Gateway-Trunks.
| ||||||||||
| 2 |
Prüfen Sie die Zertifikatskette jedes Gateways.
| ||||||||||
| 3 |
Überprüfen Sie die Antragsteller und Aussteller des Zertifikats.
| ||||||||||
| 4 |
Interpretieren Sie die Inspektionsergebnisse.
Ein Gateway wird nur dann als nicht betroffen bestätigt, wenn keiner der aufgelisteten Roots erscheint und der Trunk in Control Hub online ist. | ||||||||||
| 5 |
Ersetzen Sie eine betroffene Zertifikatskette.
| ||||||||||
| 6 |
Überprüfen Sie die Local Gateway-Konnektivität.
|
Nächste Schritte
Wenn die Kette korrekt erscheint, der Trunk aber offline, beeinträchtigt oder unbekannt bleibt:
- Vergewissern Sie sich, dass das Zertifikat gültig und korrekt installiert ist.
- Überprüfen Sie die komplette Zwischenzertifikationskette und die erwartete Zertifikatidentität.
- Überprüfen Sie die TLS-Konnektivität und die Fehler bei der Zertifikatsvalidierung auf dem Gateway.
- Wenden Sie sich an Ihren Zertifikatsanbieter, Cisco Partner oder Cisco Technical Assistance Center (TAC), falls das Problem weiterhin besteht. Wenn Sie Kontakt aufnehmenCisco Technical Assistance Center, geben Sie Ihre Unternehmens-ID, die betroffenen Trunk-Daten, den Gateway-Hostnamen, Informationen zur Zertifikatskette und relevante TLS-Fehlermeldungen an.
Verwandte Informationen:
