Благодарим за обратната връзка.

Това е, за да Ви информираме за предстояща промяна в политиката на браузъра 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 за удостоверяване както на сървър, така и на клиент.

Всички приложения или услуги на трети страни в клиентската среда, свързващи UC приложения в Dedicated Instance чрез TLS или mTLS връзки, трябва да използват същата верига от сертификати като UC приложенията в Dedicated Instance. Ако хранилището за доверени сертификати на клиентските системи или приложения не включва необходимите IdenTrust сертификационни органи, новият коренен сертификат трябва да бъде импортиран, за да се предотврати... TLS/mTLS неуспехи във връзката.

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

      Коренен CA: IdenTrust публичен сектор коренен CA 1

      Алтернативна страница за изтегляне: Изтегляния за поддръжка на IdenTrust

      Issuing/Sub Калифорния: IdenTrust публичен секторен сървър CA 1.

   За повечето приложения, доверието към Root CA е достатъчно, ако сървърът предоставя пълната верига. The Issuing/Sub CA е полезно да се включи за приложения, които изискват междинният сертификат да бъде импортиран отделно.

Коренният 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.

Интеграциите с трети страни изискват първично валидиране от страна на клиента.

За всякакви приложения или услуги на трети страни, които установяват TLS/mTLS За връзки с приложения за UC за специализирани инстанции, клиентите трябва да следват действията, посочени в Промени в сертификатите на публичния CA, засягащи специализираната инстанция.

Ще трябва да си сътрудничите директно с вашия външен доставчик или ИТ администратор, ако са необходими актуализации на хранилището за доверени данни. Промените в хранилищата за доверени сертификати на трети страни или в поведението за валидиране на сертификати са извън отговорностите на Cisco и Cisco не може да съдейства с конфигурациите или отстраняването на неизправности на доверени сертификати на трети страни.

Клиентите могат да валидират свързаността и доверието за новия публичен коренен 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 ТРЯБВА ДА ПРЕДПРИЕМАТ СЕГА