Dziękujemy za opinię.

Ma to na celu poinformowanie użytkownika o nadchodzącej zmianie zasad przeglądarki Google Chrome, która ma wpływ na wydawanie publicznych certyfikatów TLS oraz nakreślenie działań, jakie Cisco podejmie w celu zapewnienia ciągłego wsparcia dla wzajemnych połączeń TLS (MTL) w środowiskach Cisco Webex Calling dedykowanych instancji i UCM Cloud.

Począwszy od 1 lutego ²⁰ 27 r., Publiczne organy certyfikacji (CA) zawarte w programie Google Chrome Trust przestaną podpisywać certyfikaty zawierające rozszerzone użycie klucza (EKU) uwierzytelniania klienta (ClientAuth).

^{Od 15 marca 2027 r. Google będzie egzekwować zasadę wymagającą, aby publiczne certyfikaty root w Chrome Root Store wydawały certyfikaty zawierające tylko EKU uwierzytelniania serwera (ServerAuth).} W rezultacie publiczne jednostki administracyjne root w Chrome Root Store nie będą już mogły wydawać certyfikatów łą czących zarówno ekU uwierzytelniania serwera, jak i uwierzytelniania klienta w jednym certyfikacie.

Aplikacje UC dla dedykowanych instancji używają obecnie certyfikatów, które zawierają zarówno ekU uwierzytelniania serwera, jak i uwierzytelniania klienta w ramach jednego certyfikatu, aby ustanowić zaufanie dla połączeń MTL. Obsługa oddzielnych certyfikatów serwera i klienta jest teraz dostępna w wersji aplikacji UC v15su5.

Obecnie dedykowana instancja używa IDentrust Commercial Root CA 1, będącego częścią sklepu głównego Google Chrome, do podpisywania tych certyfikatów. ^{Jednak ze względu na nadchodzącą zmianę zasad Chrome, ten urząd urzędowy nie będzie już mógł wydawać certyfikatów zawierających oba EKU w jednym certyfikacie począwszy od 1 lutego 2027 r.}

Wpływ certyfikatów

Następujące certyfikaty aplikacji UC są podpisywane przy użyciu publicznego głównego urzędu urzędowego i są powszechnie używane do połączeń MTL:

Aplikacja UC	Typ certyfikatu	Wspólne połączenia MTL
Cisco Unified CM/MŚP	Tomcat/Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth przez MRA, zdalny syslog
	Menedżer połączeń/Menedżer połączeń - ECDSA	SIP Trunki, połączenia między węzłami i międzyklastrami
Cisco Unity Connection	Tomcat/Tomcat-ECDSA	SIP Proxy, SIP Trunks
Komunikator komunikacyjny Cisco i obecność	Tomcat/Tomcat-ECDSA	—
	kubek/miseczka-ECDSA	Bezpieczny SIP za pomocą CUCM, klientów zewnętrznych, SIP Proxy
	miseczka-xmpp/miseczka-xMPP-ECDSA	Federacja XMPP
Cisco Emergency Responder	Tomcat/Tomcat-ECDSA	—
Cisco Expressway	Certyfikat serwera	Mobilny i Remote Access (MRA)

Certyfikaty nie mają wpływu

Wszystkie pozostałe certyfikaty w Dedicated Instance są podpisane samodzielnie. Aby uzyskać dodatkowe informacje, zobacz Zarządzanie certyfikatami wystąpienia dedykowanego.

Aby sprostać zmianie zasad Chrome i zachować nieprzerwaną funkcjonalność MTL, firma Cisco podejmie następujące działania:

• Od 1 czerwca 2026 ^r. firma Cisco zmieni urząd publiczny główny używany do podpisywania certyfikatów aplikacji Dedicated Instance UC z IDentrust Commercial Root CA 1 na IDtrust Public Sector Root CA 1 dla wszystkich odnawiania certyfikatów.

  Proces odnawiania certyfikatu pozostaje taki sam, a Centrum alertów Control Hub powiadamia klientów za pośrednictwem alertu „Kon serwacja i awaria”, gdy zaplanowane jest odnowienie. Aby uzyskać więcej informacji, zobacz Alerty dotyczące konserwacji.

• Certyfikaty będą nadal zawierać zarówno EKU uwierzytelniania serwera, jak i klienta.

Wszelkie aplikacje lub usługi innych firm w środowisku klienta łączące aplikacje UC w wystąpieniu dedykowanym za pomocą połączeń TLS lub MTLS muszą wykorzystywać ten sam łańcuch certyfikatów, co aplikacje UC w wystąpieniu dedykowanym. Jeśli magazyn zaufania systemów klientów lub aplikacji nie zawiera jeszcze wymaganych organów certyfikacji IDEntrust, nowy certyfikat główny musi zostać zaimportowany, aby zapobiec awariom połączenia TLS/MTLS.

1. Audyt bieżących połączeń MTL
   1. Identyfikuj aplikacje, usługi innych firm lub integracje, które łączą się z aplikacjami UC w dedykowanej instancji przy użyciu protokołu TLS lub MTL.
   2. Sprawdź, czy te aplikacje ufają nowemu certyfikacji głównej publicznej: IDEntrust Public Sector Root CA 1.
2. Dodaj nowy publiczny główny CA (jeśli jest to wymagane)
   1. Jeśli IDtrust Public Sector Root CA 1 nie jest jeszcze zaufany w aplikacji klienta lub magazynie zaufania systemowego, należy go dodać.
   2. To samo można pobrać z następujących linków:

      Root CA: IDentrust Root Sektora Publicznego CA 1

      Alternatywna strona pobierania: IDtrust Support Downloads

      Wydawanie/podcertyfikacja: IDEntrust Public Sector Server CA 1.

   W przypadku większości aplikacji zaufanie do Root CA jest wystarczające, jeśli serwer prezentuje pełny łańcuch. Wydawanie/Sub CA jest korzystne dla wniosków, które wymagają oddziel nego importowania certyfikatu pośredniego.

IDtrust Public Sector Root CA 1 jest domyślnie zaufany w standardowych magazynach zaufania dla następujących systemów operacyjnych i platform:

• Microsoft Windows
• macOS
• iOS /iPadOS
• Android

W rezultacie klient jest zobowiązany jedynie do walidacji sklepów zaufanych dla tych platform, aby potwierdzić, że certyfikat główny nowego publicznego urzędu certyfikacji jest już wymieniony. Dotyczy to punktów końcowych/klientów lub systemów innych firm, które korzystają z domyślnych sklepów zaufania na tych platformach. Instrukcje dotyczące aktualizacji sklepu zaufania na każdej platformie znajdują się w poniższych sekcjach. Odpowiedzialność za przeprowadzenie tych aktualizacji spoczywa na Kliencie lub Partnerze; poniższe lin ki i kroki odnoszą się do artykułów internetowych od odpowiednich dostawców platform, a Cisco zapewnia pomoc z najwyższą starannością. Aby uzyskać dalsze wyjaśnienia, musisz współpracować bezpośrednio z odpowiednimi dostawcami platform.

Uwaga dotycząca sklepu zaufania Androida

IDtrust Public Sector Root CA 1 jest zawarty w sklepie CA systemu Android i jest domyślnie zaufany w aktualnie obsługiwanych wersjach Androida. Android nie zapewnia publicznego, specyficznego dla wersji mapowania dla poszczególnych dat wprowadzenia certyfikatu głównego. Zauf aniem jest zarządzane za pośrednictwem sklepu CA systemu Android i dystrybuowane za pośrednictwem aktualizacji systemu operacyjnego i aktualizacji systemu Google Play.

Nie jest wymagane żadne działanie klienta, chyba że magazyn zaufania systemu Android został wyraźnie zmodyfikowany przez zasady urządzenia, kontrolki zarządzania przedsiębiorstwem lub ograniczenia zauf ania specyficzne dla aplikacji.

Certyfikat główny dla sektora publicznego IDtrust 1 nie jest zawarty w sklepie głównym Google Chrome.

Aby upewnić się, że Google Chrome ufa certyfikatom wydanym w ramach tego głównego urzędu certyfikacji, klienci muszą upewni ć się, że certyfikat główny jest wyraźnie zaufany na poziomie systemu operacyjnego w lokalizacjach, które Chrome wykorzystuje do podejmowania lokalnych decyzji dotyczących zaufania.

Windows — wymagana konfiguracja zaufania

Aby upewnić się, że certyfikacja głównego jest zaufana przez Google Chrome w systemie Windows, identyfikator certyfikacji głównego sektora publicznego IDEntrust 1 musi zostać zaimportowany do jednej z następujących lokalizacji:

• Komputer lokalny → Zaufane główne organy certyfikacji

  (Zalecane dla systemów zarządzanych przez przedsiębiorstwa)

albo

• Obecny użytkownik → Zaufane instytucje certyfikacji głównej

  (Dla zaufania na poziomie użytkownika)

Certyfikaty importowane za pomocą Kreatora importu certyfikatów systemu Windows do tych lokalizacji (w tym za pośrednictwem zasad grupy) są zaufane przez Google Chrome.

Certyfikaty główne, które istnieją tylko w systemie Windows Third, nie są automatycznie zaufane przez Chrome, chyba że są wyraźnie zaimportowane, jak opisano powyżej.

Mac OS — wymagana konfiguracja zaufania

Aby upewnić się, że root CA jest zaufany przez Google Chrome w systemie macOS, należy dodać identyfikator certyfikacji głównego sektora publicznego IDTrust 1 do breloczka macOS i wyraźnie zaufać:

1. Zaimportuj certyfikat do Breloczka systemowego (zalecane) lub Keychain logowania

2. Otwórz certyfikat i ustaw:

   • Podczas korzystania z tego certyfikatu: Zawsze zaufaj

     (lub przynajmniej SSL: Always Trust)

Po zaufaniu na poziomie systemu lub użytkownika Google Chrome honoruje certyfikat jako zaufany.

Administratorzy mogą sprawdzić, które certyfikaty platformy są zaufane przez Chrome, przechodząc do: chrome: //certificate-manager/localcerts/platformcerts

Aby uzyskać więcej informacji, zobacz Często zadawane pytania Google.

Integracje stron trzecich wymagają podstawowej walidacji klienta.

W przypadku aplikacji lub usług innych firm, które nawiązują połączenia TLS/MTLS z aplikacjami UC dedyko wanej instancji, klienci muszą postępować zgodnie z działaniami wymienionymi w zmianach certyfikatów publicznych certyfikacji urzędu certyfikacji mających wpływ na wystąpienie dedykowane.

Jeśli wymagane są aktualizacje sklepu zaufania, będziesz musiał współpracować bezpośrednio z zewnętrznym dostawcą lub administratorem IT. Modyfikacje sklepów zaufania stron trzecich lub zachowań związanych z walidacją certyfikatów są poza obowiązkami Cisco, a Cisco nie może pomóc w konfiguracjach zaufania certyfikatów innych firm ani rozwiązywaniu problemów.

Klienci mogą sprawdzić poprawność nowego urzędu certyfikacji głównej publicznej za pomocą certyfikatu testowego IDtrust.

Jeśli strona zostanie otwarta pomyślnie, w Twoim środowisku zaufany zostanie certyfikat główny dla sektora publicznego IDtrust 1.

Jeśli masz pytania dotyczące tej zmiany, zasad przeglądarki Google Chrome lub aktualizacji certyfikatów w wystąpieniu dedykowanym, otwórz żądanie usługi w Centrum sterowania w obszarze cyklu życia aplikacji UC.

Klienci UCM Cloud (UCMC), którzy są właścicielami swojej domeny i zarządzają własnym odnawianiem certyfikatów aplikacji UC i którzy nie przekazali firmie Cisco uprawnień domeny do podpisywania certyfikatów aplikacji UC, będą odpowiedzialni za bezpośrednią współpracę z wybranymi publicznymi organami certyfikacji w celu rozwiązania tej zmiany. 

Klienci ci powinni również dostosować się do stosownych zaleceń dotyczących aplikacji UC (produkty telefoniczne firmy Cisco On-Prem Call Cisco Expressway) dotyczące korzystania z certyfikatów i naprawy w związku z nadchodzącymi zmianami w polityce publicznej certyfikacji i przeglądarki. Aby uzyskać więcej informacji, zobacz Role i obowiązki. 

Cisco będzie nadal dostarczać aktualizacje, gdy będzie dostępna obsługa aplikacji UC dla oddzielnych serwer ów i certyfikatów klienta. Zapoznaj się z tym dokumentem, aby uzyskać najnowsze aktualizacje.

Zmiany EKU certyfikatu: działania Klienci firmy Cisco do współpracy lokalnej MUSZĄ PODJĄĆ TERAZ