Благодарим вас за обратную связь.

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

Начиная с^{1 февраля} 2027 года, публичные центры сертификации (ЦС), входящие в программу доверия Google Chrome, прекратят подписывать сертификаты, содержащие расширенное использование ключа аутентификации клиента (clientAuth Extended Key Usage, EKU).

С^{15 марта} 2027 года Google вводит в действие политику, требующую, чтобы публичные корневые центры сертификации в корневом магазине Chrome выдавали сертификаты, содержащие только расширенное расширенное наименование (EKU) аутентификации сервера (serverAuth). В результате публичным корневым центрам сертификации в Chrome больше не будет разрешено выдавать сертификаты, объединяющие в одном сертификате расширенные коды аутентификации сервера и клиента.

В настоящее время приложения UC на выделенных экземплярах используют сертификаты, которые включают в себя как расширенные условные обозначения (EKU) аутентификации сервера, так и аутентификации клиента в одном сертификате для установления доверия к соединениям mTLS. Ожидается, что поддержка отдельных серверных и клиентских сертификатов будет внедрена в версии приложения UC v15SU5, выпуск которой запланирован на конец 2026 года.

В настоящее время Dedicated Instance использует коммерческий корневой центр сертификации IdenTrust (IdenTrust Commercial Root CA 1), входящий в хранилище корневых сертификатов Google Chrome, для подписи этих сертификатов. Однако в связи с предстоящим изменением политики Chrome, начиная с 1^{февраля 2027}года этому центру сертификации будет запрещено выдавать сертификаты, содержащие оба расширенные условные обозначения (EKU) в одном сертификате.

Затронутые сертификаты

Следующие сертификаты приложений UC подписаны с использованием публичного корневого центра сертификации и обычно используются для соединений mTLS:

заявка в Калифорнийский университет	Тип сертификата	Распространенные соединения mTLS
Cisco Unified CM / МСП	Томкэт / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth через MRA, удаленный системный журнал
	CallManager / CallManager-ECDSA	SIP-транки, межузловые и межкластерные соединения
Cisco Unity Connection	Томкэт / Tomcat-ECDSA	SIP-прокси, SIP-транки
Cisco IM and Presence	Томкэт / Tomcat-ECDSA	—
	чашка / cup-ECDSA	Защита SIP с помощью CUCM, сторонних клиентов, SIP-прокси
	cup-xmpp / cup-xmpp-ECDSA	Федерация XMPP
Ответчик Cisco для экстренных ситуаций	Томкэт / Tomcat-ECDSA	—
Cisco Expressway	Сертификат сервера	Доступ с мобильных устройств и удаленный доступ (MRA)

Сертификаты не затронуты

Все остальные сертификаты в выделенном экземпляре являются самоподписанными. Для получения дополнительной информации см. Управление сертификатами выделенного экземпляра.

Для решения проблемы, связанной с изменением политики Chrome, и обеспечения бесперебойной работы mTLS, компания Cisco предпримет следующие действия:

• С 1 июня2026 г.компания Cisco заменит публичный корневой центр сертификации (Public Root CA), используемый для подписи сертификатов приложений Dedicated Instance UC, с IdenTrust Commercial Root CA 1 на IdenTrust Public Sector Root CA 1 для всех продлений сертификатов.

  Процесс обновления сертификатов остается прежним, и Центр оповещений Control Hub Alerts Center уведомляет клиентов через оповещение "Техническое обслуживание и отключение" о планируемом обновлении. Для получения дополнительной информации см. Предупреждения о техническом обслуживании.

• Сертификаты по-прежнему будут включать в себя расширенные условные единицы (EKU) для аутентификации как сервера, так и клиента.

Любые сторонние приложения или сервисы в среде клиента, подключающиеся к приложениям UC в выделенном экземпляре с использованием соединений TLS или mTLS, должны использовать ту же цепочку сертификатов, что и приложения UC в выделенном экземпляре. Если хранилище доверенных сертификатов систем или приложений клиента еще не содержит необходимые центры сертификации IdenTrust, необходимо импортировать новый корневой сертификат, чтобы предотвратить... TLS/mTLS Сбои подключения.

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

      Корневой CA: Корневой центр сертификации Идентруст Public секторе 1

      Альтернативная страница загрузки: Загрузка справки службы поддержки IdenTrust

      Issuing/Sub КА: IdenTrust Public Sector Server CA 1.

   Для большинства приложений достаточно доверять корневому центру сертификации, если сервер предоставляет полную цепочку сертификатов. Он Issuing/Sub Включение сертификата центра сертификации (CA) целесообразно для приложений, требующих отдельного импорта промежуточного сертификата.

Центр сертификации IdenTrust Public Sector Root CA 1 по умолчанию считается доверенным в стандартных хранилищах доверенных сертификатов для следующих операционных систем и платформ:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

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

Примечание к магазину доверенных сертификатов Android

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

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

Сервер IdenTrust Public Sector Root CA 1 не входит в магазин root-прав Google Chrome.

Чтобы гарантировать, что Google Chrome доверяет сертификатам, выданным этим корневым центром сертификации, клиенты должны обеспечить явное доверие к корневому сертификату на уровне операционной системы в тех местах, которые Chrome использует для принятия решений о доверии на локальном уровне.

Windows — требуется настройка доверия

Чтобы гарантировать, что корневой центр сертификации (CA) будет считаться доверенным для Google Chrome в Windows, необходимо импортировать IdenTrust Public Sector Root CA 1 в одно из следующих мест:

• Локальный компьютер → Доверенные корневые центры сертификации

  (Рекомендуется для систем, управляемых предприятием)

или

• Текущий пользователь → Доверенные корневые центры сертификации

  (Для обеспечения доверия на уровне пользователя)

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

Корневые сертификаты, существующие только в сторонних сервисах Windows, не получают автоматического доверия от Chrome, если они не были явно импортированы, как описано выше.

Mac OS — требуется настройка доверия.

Чтобы гарантировать, что корневой центр сертификации (CA) будет считаться доверенным для Google Chrome в macOS, необходимо добавить IdenTrust Public Sector Root CA 1 в связку ключей macOS и явно указать, что ему доверяют:

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

2. Откройте сертификат и установите следующие параметры:

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

     (или, как минимум, SSL: Всегда доверяйте)

После подтверждения доверия на системном или пользовательском уровне Google Chrome будет считать сертификат доверенным.

Администраторы могут проверить, каким сертификатам платформы доверяет Chrome, перейдя по следующей ссылке: chrome://certificate-manager/localcerts/platformcerts

Для получения дополнительной информации см. Часто задаваемые вопросы Google.

Для интеграции со сторонними сервисами требуется предварительная проверка со стороны клиента.

Для любых сторонних приложений или сервисов, которые устанавливают TLS/mTLS Для подключения к приложениям Dedicated Instance UC клиентам необходимо выполнить действия, указанные в Изменения сертификатов публичного центра сертификации, влияющие на Dedicated Instance.

Для обновления хранилища доверенных сертификатов вам потребуется напрямую взаимодействовать со сторонним поставщиком или ИТ-администратором. Внесение изменений в хранилища доверенных сертификатов сторонних разработчиков или в алгоритмы проверки сертификатов выходит за рамки ответственности Cisco, и Cisco не может оказывать помощь в настройке или устранении неполадок, связанных с доверием к сертификатам сторонних разработчиков.

Клиенты могут проверить подключение и доверие к новому публичному корневому центру сертификации, получив доступ к следующему тестовому сертификату IdenTrust.

Если этот сертификат успешно открывается без предупреждений о доверии, значит, корневой центр сертификации IdenTrust Public Sector Root CA 1 уже является доверенным в среде.

Если у вас возникли вопросы относительно этого изменения, политики браузера Google Chrome или обновлений сертификатов в выделенном экземпляре, откройте запрос на обслуживание в Центре управления в разделе Жизненный цикл приложения UC.

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

Эти клиенты также должны следовать рекомендациям соответствующего продукта UC ( Продукты Cisco для локальных вызовов и Cisco Expressway) относительно использования сертификатов и устранения проблем, связанных с предстоящими изменениями в публичном центре сертификации и политике браузеров. Для получения дополнительной информации см. Роли и обязанности.

Компания Cisco продолжит предоставлять обновления по мере появления поддержки отдельных серверных и клиентских сертификатов в приложениях UC. Актуальную информацию можно найти в этом документе.

Изменения в расширенном расширенном условии сертификата: Действия, которые клиенты Cisco On-premises Collaboration ДОЛЖНЫ предпринять СЕЙЧАС