Това е, за да Ви информираме за предстояща промяна в политиката на браузъра Google Chrome, която ще окаже влияние върху издаването на публични TLS сертификати, и да очертаем действията, които Cisco ще предприеме, за да осигури непрекъсната поддръжка за взаимни TLS (mTLS) връзки в среди на Cisco Webex Calling Dedicated Instance и UCM Cloud.

От 1 февруари 2027 г. публичните сертифициращи органи (CA), включени в програмата Google Chrome Trust, ще спрат да подписват сертификати, които включват разширено използване на ключ (EKU) за удостоверяване на клиента (clientAuth).

В сила от 15 март 2027 г. Google ще наложи политика, изискваща публичните коренни сертифициращи органи (ПУС) в коренното хранилище на Chrome да издават сертификати, съдържащи само EKU за удостоверяване на сървъра (serverAuth). В резултат на това, публичните коренни сертифициращи центрове (PUC) в коренното хранилище на Chrome вече няма да имат право да издават сертификати, които комбинират EKU за удостоверяване на сървъра и удостоверяване на клиента в един сертификат.

Приложенията за UC за специализирани екземпляри в момента използват сертификати, които включват EKU за удостоверяване на сървъра и удостоверяване на клиента в рамките на един сертификат, за да установят доверие за mTLS връзки. Очаква се поддръжката за отделни сертификати за сървър и клиент да бъде въведена с версията на UC приложението v15SU5, планирана за по-късно през 2026 г.

В момента Dedicated Instance използва IdenTrust Commercial Root CA 1, част от Google Chrome Root Store, за да подписва тези сертификати. Въпреки това, поради предстоящата промяна в правилата на Chrome, този CA вече няма да има право да издава сертификати, съдържащи и двата EKU в един сертификат, считано от 1 февруари2027 г.

Засегнати сертификати

Следните сертификати за UC приложения са подписани с помощта на публичен коренен CA и обикновено се използват за mTLS връзки:

Приложение за UC	Тип на сертификата	Често срещани mTLS връзки
Cisco Unified CM / МСП	Котаракът / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth през MRA, отдалечен Syslog
	Мениджър на обаждания / CallManager-ECDSA	SIP Trunks, междувъзлови и междуклъстерни връзки
Връзка към единица на Cisco	Котаракът / Tomcat-ECDSA	SIP прокси, SIP трънкове
Незабавни съобщения и присъствие на Cisco	Котаракът / Tomcat-ECDSA	—
	чаша / чаша-ECDSA	Защитен SIP с CUCM, клиенти на трети страни, SIP прокси
	чаша-xmpp / чаша-xmpp-ECDSA	XMPP федериране
Cisco Emergency Responder	Котаракът / Tomcat-ECDSA	—
Автомагистрала Сиско	Сертификат на сървъра	Мобилен и отдалечен достъп (MRA)

Сертификатите не са засегнати

Всички останали сертификати в Dedicated Instance са самоподписани. За допълнителна информация вижте Управление на сертификати за специални екземпляри.

За да се справи с промяната в политиката на Chrome и да поддържа непрекъсната функционалност на mTLS, Cisco ще предприеме следните действия:

• В сила от 1 юни2026 г., Cisco ще превключи публичния коренен CA, използван за подписване на сертификати за UC приложения за специални екземпляри, от IdenTrust Commercial Root CA 1 на IdenTrust Public Sector Root CA 1 за всички подновявания на сертификати.

  Процесът на подновяване на сертификата остава същият и Центърът за предупреждения на Control Hub уведомява клиентите чрез предупреждението „Поддръжка и прекъсване“, когато подновяването е планирано. За повече информация вижте Сигнали за поддръжка.

• Сертификатите ще продължат да включват EKU за удостоверяване както на сървър, така и на клиент.

Клиентите и партньорите трябва да изпълнят следните действия, за да осигурят непрекъсната съвместимост на услугите :

1. Одит на текущите mTLS връзки
   1. Идентифицирайте публични TLS сертификати, които включват EKU за удостоверяване на клиента.
   2. Проверете дали свързващите се приложения се доверяват на новия публичен коренен CA.
2. Добавете новия публичен коренен CA (ако е необходимо)
   1. Ако IdenTrust Public Sector Root CA 1 все още не е надежден във вашата среда, той трябва да бъде добавен.
   2. Коренният сертификат може да бъде изтеглен от публичното хранилище IdenTrust.

Коренният CA 1 на IdenTrust Public Sector е доверен по подразбиране в стандартните хранилища за доверени данни за следните операционни системи и платформи:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

В резултат на това не се изисква действие от страна на клиента за крайни точки или системи, използващи хранилища за доверени данни по подразбиране на тези платформи, освен ако хранилището за доверени данни не е било изрично променено или ограничено от политиката на клиента.

Бележка за доверено хранилище на Android

Коренният CA 1 на IdenTrust Public Sector е включен в хранилището на CA на системата Android и е надежден по подразбиране в поддържаните в момента версии на Android. Android не предоставя публично, специфично за версията съпоставяне за датите на въвеждане на отделни коренни сертификати. Доверието се управлява чрез магазина на CA за системата Android и се разпространява чрез актуализации на операционната система и системните актуализации на Google Play.

Не се изисква действие от страна на клиента, освен ако хранилището за доверени данни на системата Android не е било изрично променено от правилата на устройството, контролите за управление на предприятието или ограниченията за доверие, специфични за приложението.

Коренният сертифициращ орган 1 на IdenTrust за публичен сектор не е включен в коренното хранилище на Google Chrome.

За да се гарантира, че Google Chrome се доверява на сертификати, издадени под този коренен CA, клиентите трябва да се уверят, че коренният сертификат е изрично надежден на ниво операционна система в местоположенията, които Chrome използва за локални решения за доверие.

Windows – необходима конфигурация на доверие

За да се гарантира, че Google Chrome в Windows доверява на коренния CA, IdenTrust Public Sector Root CA 1 трябва да бъде импортиран в едно от следните местоположения:

• Локален компютър → Доверени коренни сертифициращи органи

  (Препоръчва се за системи, управлявани от предприятието)

или

• Текущ потребител → Доверени коренни сертифициращи органи

  (За доверие на потребителско ниво)

Сертификатите, импортирани чрез съветника за импортиране на сертификати на Windows в тези местоположения (включително чрез групови правила), са надеждни за Google Chrome.

Коренните сертификати, които съществуват само в Windows Third-Party, не се считат автоматично за надеждни от Chrome, освен ако не бъдат изрично импортирани, както е описано по-горе.

Mac OS – необходима конфигурация за доверие

За да се гарантира, че Google Chrome в macOS доверява на коренния CA, IdenTrust Public Sector Root CA 1 трябва да бъде добавен към macOS Keychain и изрично да му бъде доверен:

1. Импортирайте сертификата в системната ключодържател (препоръчително) или ключодържателя за вход

2. Отворете сертификата и задайте:

   • Когато използвате този сертификат: Винаги се доверявай

     (или поне SSL: Винаги се доверявай)

След като сертификатът е надежден на системно или потребителско ниво, Google Chrome ще го приеме като надежден.

Администраторите могат да проверят кои сертификати на платформата са надеждни за Chrome, като отворят: chrome://certificate-manager/localcerts/platformcerts

За повече информация вижте ЧЗВ на Google.

Интеграциите с трети страни представляват основната област, изискваща валидиране от страна на клиента.

За всички приложения или услуги на трети страни, които установяват mTLS връзки с приложения за UC за специални екземпляри, клиентите трябва:

• Проверете дали системата на третата страна се доверява на IdenTrust Public Sector Root CA 1
• Работете директно с доставчика на трета страна, ако са необходими актуализации на хранилището за доверени данни или промени в CA

Клиентите могат да валидират свързаността и доверието за новия публичен коренен CA, като получат достъп до следния тестов сертификат IdenTrust.

Ако този сертификат се отвори успешно без предупреждения за доверие, IdenTrust Public Sector Root CA 1 вече е надежден в средата.

Ако имате въпроси относно тази промяна, правилата на браузъра Google Chrome или актуализациите на сертификатите в Dedicated Instance, отворете заявка за услуга в Control Hub под UC application lifecyle.

Клиентите на UCM Cloud (UCMC), които притежават своя домейн и управляват собствените си подновявания на сертификати за UC приложения и които не са делегирали правомощия за домейн на Cisco за подписване на сертификати за UC приложения, ще бъдат отговорни за директната работа с избраните от тях публични сертифициращи органи, за да се справят с тази промяна.

Тези клиенти трябва също да се съобразят с препоръките за приложимите продукти за UC приложения ( продукти за локални обаждания на Cisco и Cisco Expressway) относно използването на сертификати и отстраняването на проблеми, свързани с предстоящите промени в политиката на публичния сертифициращ орган и браузъра. За повече информация вижте Роли и отговорности.

Cisco ще продължи да предоставя актуализации, когато стане достъпна поддръжка за UC приложения за отделни сървърни и клиентски сертификати. Вижте този документ за най-новите актуализации.

Промени в ЕКЮ на сертификата: Действия, които клиентите на Cisco On-premises Collaboration ТРЯБВА ДА ПРЕДПРИЕМАТ СЕГА