Hiermit informieren wir Sie über eine bevorstehende Änderung der Google Chrome-Browserrichtlinien, die sich auf die Ausstellung öffentlicher TLS-Zertifikate auswirkt, und erläutern die Maßnahmen, die Cisco ergreifen wird, um die fortlaufende Unterstützung von Mutual TLS (mTLS)-Verbindungen in Cisco Webex Calling Dedicated Instance- und UCM Cloud-Umgebungen sicherzustellen.

Ab dem^{1. Februar} 2027 werden die im Google Chrome Trust-Programm enthaltenen öffentlichen Zertifizierungsstellen (CAs) keine Zertifikate mehr signieren, die die erweiterte Schlüsselverwendung (EKU) für die Clientauthentifizierung (clientAuth) enthalten.

Mit Wirkung vom^{15. März} 2027 wird Google eine Richtlinie durchsetzen, die vorschreibt, dass öffentliche Stammzertifizierungsstellen im Chrome Root Store Zertifikate ausstellen müssen, die ausschließlich die Server Authentication (serverAuth) EKU enthalten. Als Folge davon ist es öffentlichen Stammzertifizierungsstellen im Chrome-Stammzertifikatsspeicher nicht mehr gestattet, Zertifikate auszustellen, die sowohl Serverauthentifizierungs- als auch Clientauthentifizierungs-EKUs in einem einzigen Zertifikat kombinieren.

Dedicated Instance UC-Anwendungen verwenden derzeit Zertifikate, die sowohl Server Authentication als auch Client Authentication EKUs in einem einzigen Zertifikat enthalten, um Vertrauen für mTLS-Verbindungen herzustellen. Die Unterstützung für separate Server- und Clientzertifikate wird voraussichtlich mit der UC-Anwendungsversion v15SU5 eingeführt, die für später im Jahr 2026 geplant ist.

Aktuell verwendet Dedicated Instance die kommerzielle Stammzertifizierungsstelle IdenTrust Commercial Root CA 1, die Teil des Google Chrome Root Store ist, um diese Zertifikate zu signieren. Aufgrund der bevorstehenden Änderung der Chrome-Richtlinien ist es dieser Zertifizierungsstelle jedoch ab dem 1. Februar^st, 2027 nicht mehr gestattet, Zertifikate auszustellen, die beide EKUs in einem einzigen Zertifikat enthalten.

Betroffene Zertifikate

Die folgenden UC-Anwendungszertifikate sind mit einer öffentlichen Stammzertifizierungsstelle signiert und werden häufig für mTLS-Verbindungen verwendet:

UC-Antrag	Zertifikatstyp	Gemeinsame mTLS-Verbindungen
Cisco Unified CM / KMU	Kater / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth über MRA, Remote-Syslog
	CallManager / CallManager-ECDSA	SIP-Trunks, Verbindungen zwischen Knoten und Clustern
Cisco Unity Connection	Kater / Tomcat-ECDSA	SIP-Proxy, SIP-Trunks
Cisco IM- und Anwesenheitsdienst	Kater / Tomcat-ECDSA	—
	Tasse / Cup-ECDSA	Sicheres SIP mit CUCM, Drittanbieter-Clients und SIP-Proxy
	cup-xmpp / cup-xmpp-ECDSA	XMPP-Verbund
Cisco Emergency Responder	Kater / Tomcat-ECDSA	—
Cisco Expressway	Serverzertifikat	Mobile und Remote Access (MRA)

Zertifikate nicht betroffen

Alle übrigen Zertifikate in der dedizierten Instanz sind selbstsigniert. Weitere Informationen finden Sie unter Verwaltung von Zertifikaten dedizierter Instanzen.

Um der Änderung der Chrome-Richtlinien Rechnung zu tragen und die unterbrechungsfreie mTLS-Funktionalität aufrechtzuerhalten, wird Cisco folgende Maßnahmen ergreifen:

• Mit Wirkung zum^{1. Juni 2026 wird Cisco die öffentliche Stammzertifizierungsstelle, die für die Signierung von Dedicated Instance UC}- Anwendungszertifikaten verwendet wird, von IdenTrust Commercial Root CA 1 auf IdenTrust Public Sector Root CA 1 für alle Zertifikatserneuerungen umstellen.

  Der Prozess der Zertifikatserneuerung bleibt unverändert, und das Control Hub Alerts Center benachrichtigt die Kunden über die Warnung "Wartung und Ausfall", wenn die Erneuerung geplant ist. Weitere Informationen finden Sie unter Wartungshinweise.

• Zertifikate werden weiterhin sowohl Server- als auch Client-Authentifizierungs-EKUs enthalten.

Kunden und Partner müssen die folgenden Maßnahmen ergreifen, um die fortlaufende Servicekompatibilität sicherzustellen. :

1. Aktuelle mTLS-Verbindungen prüfen
   1. Identifizieren Sie öffentliche TLS-Zertifikate, die die Client Authentication EKU enthalten.
   2. Überprüfen Sie, ob die verbundenen Anwendungen der neuen öffentlichen Stammzertifizierungsstelle vertrauen.
2. Fügen Sie die neue öffentliche Stammzertifizierungsstelle hinzu (falls erforderlich).
   1. Falls die IdenTrust Public Sector Root CA 1 in Ihrer Umgebung noch nicht als vertrauenswürdig eingestuft ist, muss sie hinzugefügt werden.
   2. Das Root-Zertifikat kann aus dem öffentlichen RepositoryIdenTrust heruntergeladen werden.

Die IdenTrust Public Sector Root CA 1 wird in den Standard-Truststores für die folgenden Betriebssysteme und Plattformen standardmäßig als vertrauenswürdig eingestuft:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

Daher ist für Endpunkte oder Systeme, die auf diesen Plattformen Standard-Truststores verwenden, keine Kundenmaßnahme erforderlich, es sei denn, der Truststore wurde durch Kundenrichtlinien explizit geändert oder eingeschränkt.

Android Trust Store-Hinweis

Die IdenTrust Public Sector Root CA 1 ist im Android-System-CA-Store enthalten und wird auf den aktuell unterstützten Android-Versionen standardmäßig als vertrauenswürdig eingestuft. Android stellt keine öffentliche, versionsspezifische Zuordnung der Einführungsdaten einzelner Stammzertifikate bereit. Vertrauen wird über den Android-System-CA-Store verwaltet und über Betriebssystem-Updates und Google Play-System-Updates verteilt.

Ein Eingreifen des Kunden ist nur dann erforderlich, wenn der Truststore des Android-Systems explizit durch Geräterichtlinien, Unternehmensverwaltungssteuerungen oder anwendungsspezifische Vertrauenseinschränkungen geändert wurde.

Die IdenTrust Public Sector Root CA 1 ist nicht im Google Chrome Root Store enthalten.

Um sicherzustellen, dass Google Chrome Zertifikaten vertraut, die unter dieser Stammzertifizierungsstelle ausgestellt wurden, müssen Kunden gewährleisten, dass das Stammzertifikat auf Betriebssystemebene an den Stellen, die Chrome für lokale Vertrauensentscheidungen verwendet, explizit als vertrauenswürdig eingestuft wird.

Windows – erforderliche Vertrauenskonfiguration

Um sicherzustellen, dass die Stammzertifizierungsstelle von Google Chrome unter Windows als vertrauenswürdig eingestuft wird, muss die IdenTrust Public Sector Root CA 1 an einem der folgenden Speicherorte importiert werden:

• Lokaler Computer → Vertrauenswürdige Stammzertifizierungsstellen

  (Empfohlen für unternehmensweit verwaltete Systeme)

oder

• Aktueller Benutzer → Vertrauenswürdige Stammzertifizierungsstellen

  (Für Vertrauenswürdigkeit auf Benutzerebene)

Zertifikate, die mithilfe des Windows-Zertifikatimport-Assistenten an diese Speicherorte importiert wurden (auch über Gruppenrichtlinien), werden von Google Chrome als vertrauenswürdig eingestuft.

Stammzertifikate, die nur im Windows-Drittanbieterverzeichnis vorhanden sind, werden von Chrome nicht automatisch als vertrauenswürdig eingestuft, es sei denn, sie werden explizit wie oben beschrieben importiert.

Mac OS – erforderliche Vertrauenskonfiguration

Um sicherzustellen, dass die Stammzertifizierungsstelle von Google Chrome unter macOS als vertrauenswürdig eingestuft wird, muss die IdenTrust Public Sector Root CA 1 zum macOS-Schlüsselbund hinzugefügt und explizit als vertrauenswürdig eingestuft werden:

1. Importieren Sie das Zertifikat in den System-Schlüsselbund (empfohlen) oder den Anmelde-Schlüsselbund.

2. Öffnen Sie das Zertifikat und stellen Sie Folgendes ein:

   • Bei Verwendung dieses Zertifikats: Vertraue immer

     (oder zumindest SSL: (Immer vertrauen)

Sobald das Zertifikat auf System- oder Benutzerebene als vertrauenswürdig eingestuft wird, behandelt Google Chrome es entsprechend.

Administratoren können überprüfen, welchen Plattformzertifikaten Chrome vertraut, indem sie zu folgender Adresse navigieren: chrome://certificate-manager/localcerts/platformcerts

Weitere Informationen finden Sie in den Google FAQ.

Die Integration von Drittanbietern stellt den Hauptbereich dar, der eine Kundenvalidierung erfordert.

Für alle Drittanbieteranwendungen oder -dienste, die mTLS-Verbindungen mit Dedicated Instance UC-Anwendungen herstellen, müssen Kunden Folgendes beachten:

• Überprüfen Sie, ob das Drittsystem der IdenTrust Public Sector Root CA 1 vertraut.
• Arbeiten Sie direkt mit dem Drittanbieter zusammen, falls Aktualisierungen des Truststores oder Änderungen an der Zertifizierungsstelle erforderlich sind.

Kunden können die Konnektivität und Vertrauenswürdigkeit der neuen öffentlichen Stammzertifizierungsstelle überprüfen, indem sie auf das folgende IdenTrust-Testzertifikatzugreifen.

Wenn dieses Zertifikat ohne Vertrauenswarnungen erfolgreich geöffnet wird, ist die IdenTrust Public Sector Root CA 1 in der Umgebung bereits als vertrauenswürdig eingestuft.

Wenn Sie Fragen zu dieser Änderung, den Richtlinien des Google Chrome-Browsers oder Zertifikatsaktualisierungen in Dedicated Instance haben, öffnen Sie eine Serviceanfrage im Control Hub unter UC Anwendungslebenszyklus.

UCM Cloud (UCMC)-Kunden, die ihre Domain besitzen und die Erneuerung ihrer UC-Anwendungszertifikate selbst verwalten und die die Domainautorisierung für die Signierung von UC-Anwendungszertifikaten nicht an Cisco delegiert haben, sind dafür verantwortlich, direkt mit den von ihnen gewählten öffentlichen Zertifizierungsstellen zusammenzuarbeiten, um diese Änderung umzusetzen.

Diese Kunden sollten sich außerdem an die Empfehlungen der jeweiligen UC-Anwendungsprodukte ( Cisco On-Premise-Telefonieprodukte und Cisco Expressway) hinsichtlich der Zertifikatsnutzung und der Behebung von Problemen im Zusammenhang mit den bevorstehenden Änderungen der Richtlinien für öffentliche Zertifizierungsstellen und Browser halten. Weitere Informationen finden Sie unter Rollen und Verantwortlichkeiten.

Cisco wird weiterhin Aktualisierungen bereitstellen, sobald die Unterstützung für separate Server- und Clientzertifikate in UC-Anwendungen verfügbar ist. Die aktuellsten Informationen finden Sie in diesem Dokument.

Änderungen der EKU-Zertifikate: Maßnahmen, die Cisco On-Premises Collaboration-Kunden JETZT ergreifen MÜSSEN