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

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

З 15 березня 2027 року Google запроваджуватиме політику, яка вимагатиме від публічних кореневих центрів сертифікації (Public Root ЦС) у кореневому сховищі Chrome видавати сертифікати, що містять лише ключ ключа автентифікації сервера (serverAuth). В результаті, публічним кореневим центрам сертифікації (CCA) у кореневому сховищі Chrome більше не буде дозволено видавати сертифікати, які поєднують в одному сертифікаті EKU для автентифікації сервера та автентифікації клієнта.

Програми UC для виділених екземплярів наразі використовують сертифікати, які містять EKU для автентифікації сервера та автентифікації клієнта в одному сертифікаті, щоб встановити довіру для з’єднань mTLS. Очікується, що підтримка окремих сертифікатів сервера та клієнта буде запроваджена з випуском програми UC v15SU5, вихід якого заплановано на пізніший період 2026 року.

Наразі виділений екземпляр використовує IdenTrust Commercial Root CA 1, що є частиною кореневого сховища Google Chrome, для підписання цих сертифікатів. Однак, через майбутню зміну політики Chrome, цей центр сертифікації більше не зможе видавати сертифікати, що містять обидва EKU в одному сертифікаті, починаючи з 1 лютого2027 року.

Сертифікати, на які це впливає

Наступні сертифікати UC-застосунків підписані за допомогою публічного кореневого центру сертифікації та зазвичай використовуються для mTLS-підключень:

Застосування UC	Тип сертифіката	Поширені з’єднання mTLS
Уніфіковане керування контентом Cisco / МСП	Томкіт / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth через MRA, віддалений системний журнал
	Менеджер викликів / CallManager-ECDSA	SIP-транки, міжвузлові та міжкластерні з'єднання
Cisco Unity Connection	Томкіт / Tomcat-ECDSA	SIP-проксі, SIP-транки
Cisco IM and Presence	Томкіт / Tomcat-ECDSA	—
	чашка / чашка-ECDSA	Безпечний SIP з CUCM, сторонніми клієнтами, SIP-проксі
	чашка-xmpp / чашка-xmpp-ECDSA	Федерація XMPP
Cisco Emergency Responder	Томкіт / Tomcat-ECDSA	—
Cisco Expressway	Сертифікат сервера	Мобільний і віддалений доступ (MRA)

Сертифікати не зазнали змін

Усі інші сертифікати у виділеному екземплярі є самопідписаними. Для отримання додаткової інформації див. Керування сертифікатами виділених екземплярів.

Щоб врахувати зміну політики Chrome та підтримувати безперебійну роботу mTLS, Cisco вживе таких заходів:

• З 1 червня2026 рокукомпанія Cisco змінить публічний кореневий центр сертифікації, який використовується для підписання сертифікатів виділених екземплярів UC-додатків, з IdenTrust Commercial Root CA 1 на IdenTrust Public Sector Root CA 1 для всіх поновлень сертифікатів.

  Процес поновлення сертифіката залишається незмінним, а Центр сповіщень Control Hub повідомляє клієнтів через сповіщення «Технічне обслуговування та збої», коли заплановано поновлення. Для отримання додаткової інформації див. Сповіщення про технічне обслуговування.

• Сертифікати й надалі міститимуть EKU для автентифікації сервера та клієнта.

Клієнти та партнери повинні виконати такі дії, щоб забезпечити постійну сумісність послуг :

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

Кореневий центр сертифікації 1 IdenTrust Public Sector є довіреним за замовчуванням у стандартних сховищах довірених сертифікатів для таких операційних систем і платформ:

• Microsoft Windows;
• macOS
• iOS / iPadOS
• Android

Як результат, для кінцевих точок або систем, що використовують сховища довірених сертифікатів за замовчуванням на цих платформах, не потрібні жодні дії клієнта, якщо сховище довірених сертифікатів не було явно змінено або обмежено політикою клієнта.

Примітка до сховища довірених даних Android

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

Клієнту не потрібні жодні дії, окрім випадків, коли сховище довірених сертифікатів системи Android було явно змінено політикою пристрою, засобами керування підприємством або обмеженнями довіри для певних програм.

Кореневий центр сертифікації IdenTrust Public Sector Root CA 1 не включено до кореневого сховища Google Chrome.

Щоб Google Chrome довіряв сертифікатам, виданим цим кореневим центром сертифікації, клієнти повинні переконатися, що кореневий сертифікат явно довірений на рівні операційної системи в місцях, які Chrome використовує для локальних рішень щодо довіри.

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

Щоб Google Chrome у Windows довіряв кореневому центру сертифікації, кореневий центр сертифікації IdenTrust Public Sector Root CA 1 необхідно імпортувати в одне з таких місць:

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

  (Рекомендовано для систем, що керуються підприємством)

або

• Поточний користувач → Довірені кореневі центри сертифікації

  (Для довіри на рівні користувача)

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

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

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

Щоб Google Chrome у macOS довіряв кореневому центру сертифікації, необхідно додати кореневий центр сертифікації IdenTrust Public Sector Root CA 1 до в’язки ключів macOS та явно позначити його як довірений:

1. Імпортуйте сертифікат у Системну в'язку ключів (рекомендовано) або В'язку ключів входу

2. Відкрийте сертифікат та встановіть:

   • Під час використання цього сертифіката: Завжди довіряй

     (або, як мінімум, SSL: Завжди довіряй)

Після того, як сертифікат буде визнано надійним на рівні системи або користувача, Google Chrome вважатиме його надійним.

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

Для отримання додаткової інформації див. Найчастіші запитання Google.

Інтеграції зі сторонніми розробниками є основною сферою, яка потребує перевірки клієнтами.

Для будь-яких сторонніх програм або служб, які встановлюють з’єднання mTLS із програмами виділених екземплярів UC, клієнти повинні:

• Перевірте, чи стороння система довіряє кореневому центру сертифікації 1 державного сектору IdenTrust.
• Працюйте безпосередньо зі стороннім постачальником, якщо потрібні оновлення сховища довірених сертифікатів або зміни ЦС.

Клієнти можуть перевірити підключення та довіру до нового публічного кореневого центру сертифікації, отримавши доступ до наступного тестового сертифіката 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 повинні виконати зараз