In diesem Artikel
Bereich
Änderung der Google Chrome-Zertifikatsrichtlinie
Dedizierte Instanzen für UC-Anwendungen – aktuelles Verhalten
dropdown icon
Folgenabschätzung
    Betroffene Zertifikate
    Zertifikate nicht betroffen
Cisco plante Abhilfemaßnahmen
Erforderliche Maßnahmen von Kunden und Partnern
dropdown icon
Überlegungen zum Standard-Truststore
    Android Trust Store-Hinweis
dropdown icon
Browserzugriffshinweise (Google Chrome)
    Windows – erforderliche Vertrauenskonfiguration
    Mac OS – erforderliche Vertrauenskonfiguration
Überlegungen zur Integration von Drittanbietern
Optionaler Validierungstest
Support
Zusätzliche Überlegungen für UCM Cloud (UCMC)-Kunden
Referenz
Änderungen an öffentlichen CA-Zertifikaten, die sich auf die dedizierte Instanz auswirken
list-menuIn diesem Artikel
list-menuFeedback?

Google Chrome implementiert eine wichtige Richtlinienänderung bezüglich der erweiterten Schlüsselverwendung (EKU) in öffentlich vertrauenswürdigen Diensten. SSL/TLS Zertifikate.

Ä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

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.

  1. Aktuelle mTLS-Verbindungen prüfen
    1. Identifizieren Sie Anwendungen, Drittanbieterdienste oder Integrationen, die über TLS oder mTLS eine Verbindung zu den UC-Anwendungen in der dedizierten Instanz herstellen.
    2. Überprüfen Sie, ob diese Anwendungen der neuen öffentlichen Stammzertifizierungsstelle vertrauen: Identrust Public Sector Root CA 1.
  2. Fügen Sie die neue öffentliche Stammzertifizierungsstelle hinzu (falls erforderlich).
    1. 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.
    2. 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:

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:

  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.

Ü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.

War dieser Artikel hilfreich für Sie?
War dieser Artikel hilfreich für Sie?