- Startseite
- /
- Artikel
Danke für Ihr Feedback.
In diesem Artikel
Feedback?Cisco entfernt das Vertrauen in bestimmte Root-CAs, die zur Validierung sicherer SIP-Verbindungen verwendet werden, nach dem Sicherheitsvorfall der eMudhra Certificate Authority (CA) vom Oktober 2026. Die Durchsetzung der betroffenen Webex Meetings SIP-Integrationen soll am 2. November 2026 beginnen. Die Einführung kann in Etappen erfolgen. Planen Sie, Ihre Änderungen vor dem 2. November abzuschließen. Kunden, deren Zertifikatsketten von den Behörden abhängen, denen das Misstrauen entgegengebracht wird, müssen das betroffene Zertifikat oder die betroffene Kette ersetzen. Andernfalls schlägt die betroffene sichere SIP-Verbindung bei der TLS-Authentifizierung fehl, wenn die aktualisierte Vertrauensrichtlinie für diese Verbindung durchgesetzt wird.
Was könnte betroffen sein
Integrationen
-
Webex MeetingsEdge Audio: Die Ein- und Auswahl von Besprechungen über betroffene Unternehmens-SIP-Verbindungen funktioniert nicht mehr, wenn die Durchsetzung diese Verbindungen erreicht.
-
Collaboration Meeting Rooms (CMR): SIP-basiertes Videogerät, das über betroffene sichere SIP-Verbindungen beitritt, schlägt fehl, wenn die Durchsetzung diese Verbindungen erreicht.
-
Zu der vom Kunden verwalteten Infrastruktur können Cisco CUBE, Expressway-E und andere Session Border Controller (SBCs) gehören. Überprüfen Sie sowohl primäre als auch redundante Systeme.
Diese Änderungen zielen auf SIP-Integrationen ab, die betroffene Zertifikatsketten verwenden; andere Zugangsmethoden für Besprechungen hängen nicht vom selben vom Kunden verwalteten SIP-Zertifikatspfad ab.
Zertifizierungsstellen
Suchen Sie nach Zertifikatsketten, die von einer der folgenden Behörden abhängen:
-
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, aber das Cross-Signing betraf eMudhra-Zwischenprodukte und ist in dieser Sicherheitsmaßnahme enthalten. Einige von Sectigo ausgestellte Zertifikate verwenden möglicherweise einen AAA-quersignierten Zertifizierungspfad, obwohl die Sectigo-Kundenzertifikate selbst nicht kompromittiert wurden.
emSign Root CA - G1 ist in dieser Misstrauensänderung nicht enthalten. Ersetzen oder entfernen Sie keine Zertifikate, nur weil sie G1 verwenden.
Überprüfen und ersetzen Sie die betroffenen Zertifikate oder Ketten
| 1 |
Identifizieren Sie den CUBE, Expressway-E oder SBC, der für die betroffene Edge-Audio- oder SIP-basierte Meeting-Integration verwendet wurde. Notieren Sie den tatsächlichen Hostnamen und den konfigurierten SIP-TLS-Port. Prüfen Sie dann das auf diesem System installierte TLS-Identitätszertifikat und alle zugehörigen Zwischenzertifikate der Zertifizierungsstelle. Auf Expressway-E kann das installierte Serverzertifikat unter Serverzertifikat eingesehen werden. Verwenden Sie für CUBE und andere SBCs das entsprechende Verfahren zur Prüfung von Lieferantenzertifikaten. Wiederholen Sie dies für Backup- und redundante Systeme. |
| 2 |
Führen Sie auf einem Computer mit installiertem OpenSSL und Netzwerkzugriff auf den SIP-TLS-Listener das entsprechende Beispiel aus:
Ersetzen Sie den Beispiel-Hostnamen und den Port durch Ihren tatsächlichen SIP-TLS-Endpunkt; der Port kann je nach Bereitstellung unterschiedlich sein. Wenn der eingehende TLS-Zugriff eingeschränkt ist, führen Sie die Prüfung von einem autorisierten Managementsystem aus. Auf Expressway-E erfordert der mit Webex verwendete SIP-TLS-Port möglicherweise ein Client-Zertifikat. Der Befehl kann dann mit einem Fehler enden, aber die Zertifikatskette wird trotzdem angezeigt. Überprüfen Sie die Einträge in der Zertifikatskette, einschließlich Betreff (e:) und Aussteller (i:). Suchen Sie nach einem der vier betroffenen CA-Namen, einschließlich eines UserTrust RSA Certification Authority-Zertifikats, ausgestellt von AAA Certificate Services. Beispiel für einen betroffenen, mit Kreuzzeichen versehenen Ketteneintrag:
|
| 3 |
Interpretieren Sie die Ergebnisse:
|
| 4 |
Kontaktieren Sie Ihren Zertifikatsanbieter oder Wiederverkäufer für ein Ersatzzertifikat oder eine alternative Zertifikatskette, die an einem Root endet, der oben nicht aufgeführt ist. Bitten Sie den Anbieter, zu bestätigen, dass die Ersatzkette für die Webex SIP-Integration geeignet ist.
Überprüfen Sie die installierte Kette erneut, um sicherzustellen, dass sie nicht mehr von den Behörden abhängt, denen das Misstrauen entgegengebracht wird .
|
| 5 |
Bestätigen Sie die Konnektivität des Meetings:
Wenn weiterhin Probleme mit der Zertifikat- oder SIP-Konnektivität bestehen, wenden Sie sich an Ihren Cisco-Partner oder Cisco Technical Assistance Center (TAC). Geben Sie Ihre Webex-Organisations-ID, den betroffenen Dienst, das betroffene System und den SIP-Hostnamen, die Details der Zertifikatskette und alle TLS- oder SIP-Fehlermeldungen an. Teilen Sie keine privaten Schlüssel. |
Verwandte Informationen
Weitere Informationen finden Sie im Folgenden:
