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

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

^{С 1 февраля 2027 года государственные центры сертификации (CA), входящие в программу Google Chrome Trust, перестанут подписывать сертификаты, включающие расширенное использование ключей аутентификации клиентов (ClientAuth) (EKU).}

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

Приложения UC для выделенных инстансов в настоящее время используют сертификаты, включающие электронные идентификаторы аутентификации сервера и аутентификации клиентов в одном сертификате, чтобы обеспечить доверие к соединениям MTLS. Поддержка отдельных сертификатов сервера и клиента теперь доступна в версии приложения UC V15su5.

В настоящее время выделенный экземпляр использует коммерческий корневой каталог IDenTrust CA 1, входящий в корневой магазин Google Chrome, для подписи этих сертификатов. Однако в связи с предстоящим изменением политики Chrome этому центру сертификации больше не будет разрешено выпускать сертификаты, содержащие оба eKU в одном сертификате, начиная с 1 февраля 2027 года^.

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

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

Приложение UC	Тип сертификата	Распространенные соединения mTLS
Cisco Unified CM/МСП	Tomcat/Tomcat-ECDSA	LDAP, Filebeat, Logstash, аутентификация SIP через MRA, удаленный системный журнал
	Диспетчер вызовов/Диспетчер вызовов — ECDSA	Транки SIP, межузловые и межкластерные соединения
Cisco Unity Connection	Tomcat/Tomcat-ECDSA	Прокси-сервер SIP, магистрали SIP
Обмен мгновенными сообщениями и присутствие Cisco	Tomcat/Tomcat-ECDSA	—
	чашка/чашка-ECDSA	Безопасный SIP с помощью CUCM, сторонних клиентов, прокси-сервера SIP
	cup-xmpp/cup-xmpp-ecdSA	Федерация XMPP
Cisco Emergency Responder	Tomcat/Tomcat-ECDSA	—
Cisco Expressway	Сертификат сервера	Мобильные устройства и Remote Access (MRA)

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

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

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

• ^{С 1 июня 2026 года Cisco переключит общедоступный корневой центр сертификации, используемый для подписи сертификатов приложений UC для выделенных инстансов, с коммерческого корневого центра сертификации IDenTrust на корневой центр IDenTrust Public Sector CA 1 для всех продлений сертификатов.}

  Процесс продления сертификата остался прежним, и центр оповещений Control Hub уведомляет клиентов предупреждением «Техническое обслуживание и перебои в работе», когда запланировано продление. Дополнительные сведения см. в разделе Оповещения о техническом обслуживании.

• Сертификаты по-прежнему будут включать электронные письма аутентификации сервера и клиента.

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

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

      Корневой центр сертификации: IDenTrust, корень государственного сектора, центр сертификации 1

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

      Выпуск/субцентр сертификации: сервер IDentTrust для государственного сектора, CA 1.

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

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

• Microsoft Windows
• macOS
• iOS/iPadOS
• Android

В результате от клиента требуется только проверить трастовые хранилища для этих платформ, чтобы убедиться, что корневой сертификат нового публичного центра сертификации уже включен в список. Это относится к конечным точкам/клиентам или сторонним системам, использующим доверительные хранилища по умолчанию на этих платформах. Инструкции по обновлению трастового хранилища на каждой платформе приведены в следующих разделах. Ответственность за выполнение этих обновлений лежит на Заказчике или Партнере; приведенные ниже ссылки и инструкции содержат ссылки на онлайн-статьи соответствующих поставщиков платформ, а Cisco предоставляет помощь, прилагая все усилия. Для получения дополнительных разъяснений вы должны работать напрямую с соответствующими поставщиками платформ.

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

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

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

Корневой каталог IDenTrust для государственного сектора CA 1 не включен в корневой магазин Google Chrome.

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

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

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

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

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

или же

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

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

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

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

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

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

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

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

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

     (или, как минимум, SSL: Always Trust)

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

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

Дополнительные сведения см. в разделе часто задаваемых вопросов Google.

Интеграция со сторонними производителями требует первичной проверки со стороны клиента.

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

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

Клиенты могут проверить новый общедоступный корневой центр сертификации, используя тестовый сертификат IDenTrust.

Если страница откроется успешно, значит, корневому сертификату IDenTrust Public Sector CA 1 в вашей среде доверяют.

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

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

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

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

Изменения в сертификате EKU: действия, которые заказчики Cisco для локальной совместной работы ДОЛЖНЫ ПРЕДПРИНЯТЬ СЕЙЧАС