- Startseite
- /
- Artikel
Google Chrome implementiert eine wichtige Richtlinienänderung bezüglich der erweiterten Schlüsselverwendung (EKU) in öffentlich vertrauenswürdigen Diensten. SSL/TLS Zertifikate.
Bereich
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.
Änderung der Google Chrome-Zertifikatsrichtlinie
Ab dem1. 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 vom15. 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.
Dedizierte Instanzen für UC-Anwendungen – aktuelles Verhalten
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. Februarst, 2027 nicht mehr gestattet, Zertifikate auszustellen, die beide EKUs in einem einzigen Zertifikat enthalten.
Folgenabschätzung
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.
Cisco plante Abhilfemaßnahmen
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 Signierungvon 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.
Erforderliche Maßnahmen von Kunden und Partnern
Alle Drittanbieteranwendungen oder -dienste in der Kundenumgebung, die UC-Anwendungen in der dedizierten Instanz über TLS- oder mTLS-Verbindungen verbinden, müssen dieselbe Zertifikatskette verwenden wie die UC-Anwendungen in der dedizierten Instanz. Falls der Truststore der Kundensysteme oder -anwendungen die erforderlichen IdenTrust-Zertifizierungsstellen noch nicht enthält, muss das neue Stammzertifikat importiert werden, um dies zu verhindern. TLS/mTLS Verbindungsfehler.
- Aktuelle mTLS-Verbindungen prüfen
- Identifizieren Sie Anwendungen, Drittanbieterdienste oder Integrationen, die über TLS oder mTLS eine Verbindung zu den UC-Anwendungen in der dedizierten Instanz herstellen.
- Überprüfen Sie, ob diese Anwendungen der neuen öffentlichen Stammzertifizierungsstelle vertrauen: Identrust Public Sector Root CA 1.
- Fügen Sie die neue öffentliche Stammzertifizierungsstelle hinzu (falls erforderlich).
- Falls die IdenTrust Public Sector Root CA 1 im Truststore der Kundenanwendung oder des Systems noch nicht als vertrauenswürdig eingestuft ist, muss sie hinzugefügt werden.
- Dasselbe kann über die folgenden Links heruntergeladen werden:
Wurzel CA: IdenTrust Public Sector Root CA 1
Alternative Downloadseite: IdentTrust Support-Downloads
Issuing/Sub CA: IdenTrust Public Sector Server CA 1.
Für die meisten Anwendungen ist es ausreichend, der Root-CA zu vertrauen, wenn der Server die vollständige Zertifizierungskette vorlegt. Der Issuing/Sub Die Einbindung einer Zertifizierungsstelle ist vorteilhaft für Anwendungen, die den separaten Import des Zwischenzertifikats erfordern.
Überlegungen zum Standard-Truststore
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.
Browserzugriffshinweise (Google Chrome)
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:
-
Importieren Sie das Zertifikat in den System-Schlüsselbund (empfohlen) oder den Anmelde-Schlüsselbund.
-
Ö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.
Überlegungen zur Integration von Drittanbietern
Integrationen von Drittanbietern erfordern eine primäre Kundenvalidierung.
Für alle Drittanbieteranwendungen oder -dienste, die sich einrichten TLS/mTLS Bei Verbindungen mit Dedicated Instance UC-Anwendungen müssen Kunden die in Änderungen des öffentlichen CA-Zertifikats, die Dedicated Instance betreffengenannten Maßnahmen befolgen.
Falls Aktualisierungen des Truststores erforderlich sind, müssen Sie direkt mit Ihrem Drittanbieter oder IT-Administrator zusammenarbeiten. Änderungen an Truststores von Drittanbietern oder am Verhaltensweisen bei der Zertifikatsvalidierung fallen nicht in den Verantwortungsbereich von Cisco, und Cisco kann bei der Konfiguration von Zertifikatsvertrauenssystemen von Drittanbietern oder bei der Fehlerbehebung keine Unterstützung leisten.
Optionaler Validierungstest
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.
Support
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.
Zusätzliche Überlegungen für UCM Cloud (UCMC)-Kunden
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.