Дякуємо за відгук.

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

Починаючи з 1 лютого ²⁰² 7 року державні органи сертифікатів (CA), включені до програми Google Chrome Trust, припинять підписувати сертифікати, які включають розширене використання ключів ( EKU) аутентифікації клієнта (ClientAuth).

Починаючи з 15 ^{березня} 2027 року, Google застосовуватиме політику, яка вимагає, щоб публічні кореневі CA в кореневому магазині Chrome видавали сертифікати, що містять лише EKU автентифікації сервера (ServerAuth). Таким чином, публічні кореневі сертифікатори в кореневому магазині Chrome більше не матимуть дозволу видавати сертифікати, які поєднують як автентифікацію сервера, так і EKU ав тентифікації клієнта в одному сертифікаті.

Програми UC виділених екземплярів наразі використовують сертифікати, які включають як ав тентифікацію сервера, так і EKU автентифікації клієнта в межах одного сертифіката для встановлення довіри для з'єднань MTL. Підтримка окремих серверних і клієнтських сертифікатів тепер доступна з випуском програми UC V15su5.

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

Постраждали сертифікати

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

Застосування UC	Тип сертифіката	Загальні MTL-з'єднання
Cisco Unified CM/МСП	Томкіт/Томкат-ECDSA	LDAP, Filebeat, Логсташ, SIP OAuth через MRA, Віддалений системний журнал
	Менеджер дзвінків/Менеджер дзвінків-ECDSA	SIP-магістралі, міжвузлові та міжкластерні з'єднання
Cisco Unity Connection	Томкіт/Томкат-ECDSA	SIP-проксі, SIP-магістралі
Швидкі повідомлення та присутність Cisco	Томкіт/Томкат-ECDSA	—
	чашка/чашка-ECDSA	Захищений SIP за допомогою CUCM, сторонніх клієнтів, SIP проксі
	чашка-xmpp/чашка-XMPP-ЕЦДСА	Федерація XMPP
Cisco Emergency Responder	Томкіт/Томкат-ECDSA	—
Cisco Expressway	Серверний сертифікат	Мобільний та Remote Access (MRA)

Сертифікати не впливають

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

Щоб усунути зміни політики Chrome і зберегти безперебійну функціональність MTL, Cisco вживає таких дій:

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

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

• Сертифікати продовжуватимуть включати як серверну, так і клієнтську автентифікацію EKU.

Будь-які сторонні програми або служби в клієнтському середовищі, які з'єднують програми UC у виділеному екземплярі за допомогою з'єднань TLS або mTLS, повинні використовувати той самий ланцюжок сертифікатів, що й програми UC у виділеному екземплярі. Якщо сховище довіри клієнтських систем або додатків ще не містить необхідних органів сертифікатів IdenTrust, новий кореневий сертифікат необхідно імпортувати, щоб запобігти збоям з'єднання TLS/MTLS.

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

      Коренева CA: IdenTrust Коренева CA для державного сектору 1

      Альтернативна сторінка завантаження: Заванта ження підтримки IdenTrust

      Випуск/Підрозділ CA: IdenTrust Сервер державного сектору CA 1.

   Для більшості додатків достатньо довіряти кореневій CA, якщо сервер представляє повний ланцюжок. Випускний/суб-CA вигідно включати для додатків, які вимагають імпор ту проміжного сертифіката окремо.

ІденTrust Public Sector Root CA 1 за замовчуванням довіряється у стандартних сховищах довіри для наступних операційних систем та платформ:

• Microsoft Windows
• МакОС
• iOS /iPadOS
• Android

Таким чином, клієнт повинен лише перевірити сховища довіри для цих платформ, щоб підтвердити, що кореневий сертифікат нової публічної CA вже перелічено. Це стосується кінцевих ток /клієнтів або сторонніх систем, які використовують сховища довіри за замовчуванням на цих платформах. Інструкції щодо оновлення довірчого сховища на кожній платформі наведені в розділах нижче. Відповідальність за виконання цих оновлень несе Клієнт або Партнер; наведені нижче посилання та кроки посилаються на онлайн-статті відповідних постачальників платформ, і Cisco надає допомогу на основі максимальних зусиль. Для подальших роз'яснень ви повинні працювати безпосередньо з відповідними постачальниками платформ.

Примітка магазину довіри Android

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

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

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

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

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

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

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

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

або

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

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

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

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

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

Щоб переконатися, що кореневу сертифікацію довіряє Google Chrome на macOS, кореневу сертифікацію для публічного сектору IdenTrust 1 потрібно додати до брелоків macOS і явно довіряти:

1. Імпорт сертифіката в системний брелок (рекомендується) або в брелок для входу

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

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

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

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

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

Докладніші відомості див. у розділі Поши рені запитання Google.

Інтеграція третіх сторін вимагає первинної перевірки клієнта.

Для будь-яких сторонніх програм або служб, які встановлюють з'єднання TLS/mTLS із програмами UC виділених екземпля рів, клієнти повинні виконувати дії, зазначені у зміні сертифікатів публічної CA, що впливають на виділений екземпляр.

Вам потрібно буде співпрацювати безпосередньо зі стороннім постачальником або ІТ-адміністратором, якщо потрібні оновлення довірчого сховища. Модифікації сторонніх сховищ довіри або поведінку перевірки сертифікатів не є обов'язками Cisco, і Cisco не може допомогти з конфігурацією довіри сертифікатів тре тіми сторонами або усуненням несправностей.

Клієнти можуть перевірити нову загальнодоступну кореневу сертифікацію за допомогою тестового сертифіката I denTrust.

Якщо сторінка успішно відкриється, у вашому середовищі буде довірена коренева CA 1 IdenTrust Public Sector .

Якщо у вас виникли запитання щодо цієї зміни, політики браузера Google Chrome або оновлень сертифікатів у виділеному ек земплярі, відкрийте запит на службу в Контрольному центрі у розділі життє вий цикл програми UC.

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

Цим клієнтам також слід відповідати рекомендаціям застосовного додаткового продукту UC (продукти локальних викликів Cisco та Cisco Expressway) щодо використання та виправлення сертифікатів, пов'язаних із майбутніми змінами політики публічної CA та браузерів. Для отримання додаткової інформації див. Ролі та обов'язки. 

Cisco продовжуватиме надавати оновлення, оскільки стане доступною підтримка додатків UC для окремих серверних та клієнтських сертифікатів. Зверніться до цього документа, щоб отримати останні оновлення.

Зміни сертифікату EKU: дії, які клієнти Cisco для лок альної співпраці ПОВИННІ ЗРОБИТИ ЗАРАЗ