- Головна
- /
- Стаття
Google Chrome впроваджує суттєву зміну політики щодо розширеного використання ключа (EKU) у публічно довірених SSL/TLS сертифікати.
Сфера доступу
Цим повідомленням повідомляємо вас про майбутню зміну політики браузера Google Chrome, яка вплине на видачу публічних сертифікатів TLS, та окреслює дії, які Cisco вживатиме для забезпечення постійної підтримки взаємних з’єднань TLS (mTLS) у середовищах Cisco Webex Calling Dedicated Instance та UCM Cloud.
Зміна політики сертифікатів Google Chrome
Починаючи з 1 лютого 2027 року, публічні центри сертифікації (CA), що входять до програми Google Chrome Trust, припинять підписувати сертифікати, що містять розширене використання ключа (EKU) для автентифікації клієнта (clientAuth).
З 15 березня 2027 року Google запроваджуватиме політику, яка вимагатиме від публічних кореневих центрів сертифікації (Public Root ЦС) у кореневому сховищі Chrome видавати сертифікати, що містять лише ключ ключа автентифікації сервера (serverAuth). В результаті, публічним кореневим центрам сертифікації (CCA) у кореневому сховищі Chrome більше не буде дозволено видавати сертифікати, які поєднують в одному сертифікаті EKU для автентифікації сервера та автентифікації клієнта.
Виділені екземпляри UC-додатків – поточна поведінка
Програми 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) |
Сертифікати не зазнали змін
Усі інші сертифікати у виділеному екземплярі є самопідписаними. Для отримання додаткової інформації див. Керування сертифікатами виділених екземплярів.
Заплановане виправлення Cisco
Щоб врахувати зміну політики Chrome та підтримувати безперебійну роботу mTLS, Cisco вживе таких заходів:
- З 1 червня2026 рокукомпанія Cisco змінить публічний кореневий центр сертифікації, який використовується для підписання сертифікатів виділених екземплярів UC-додатків, з IdenTrust Commercial Root CA 1 на IdenTrust Public Sector Root CA 1 для всіх поновлень сертифікатів.
Процес поновлення сертифіката залишається незмінним, а Центр сповіщень Control Hub повідомляє клієнтів через сповіщення «Технічне обслуговування та збої», коли заплановано поновлення. Для отримання додаткової інформації див. Сповіщення про технічне обслуговування.
- Сертифікати й надалі міститимуть EKU для автентифікації сервера та клієнта.
Необхідні дії клієнтів та партнерів
Будь-які сторонні програми або служби в середовищі клієнта, що підключають програми UC у виділеному екземплярі за допомогою з’єднань TLS або mTLS, повинні використовувати той самий ланцюжок сертифікатів, що й програми UC у виділеному екземплярі. Якщо сховище довірених сертифікатів клієнтських систем або програм ще не містить необхідних центрів сертифікації IdenTrust, новий кореневий сертифікат необхідно імпортувати, щоб запобігти TLS/mTLS збої з'єднання.
- Аудит поточних mTLS-підключень
- Визначте програми, сторонні служби або інтеграції, які підключаються до програм UC у виділеному екземплярі за допомогою TLS або mTLS.
- Перевірте, чи довіряють ці програми новому публічному кореневому центру сертифікації: Кореневий центр сертифікації IdenTrust публічного сектору 1.
- Додайте новий публічний кореневий центр сертифікації (за потреби)
- Якщо IdenTrust Public Sector Root CA 1 ще не є довіреним у клієнтській програмі або системному сховищі довірених сертифікатів, його необхідно додати.
- Те саме можна завантажити за наступними посиланнями:
Кореневий ЦС: Корінь державного сектору IdenTrust CA 1
Альтернативна сторінка завантаження: Завантаження підтримки IdenTrust
Issuing/Sub Каліфорнія: Сервер IdenTrust публічного сектору CA 1.
Для більшості застосунків довіри до кореневого центру сертифікації достатньо, якщо сервер надає повний ланцюжок. The Issuing/Sub ЦС корисно включати для програм, які потребують окремого імпорту проміжного сертифіката.
Міркування щодо сховища довірених сертифікатів за замовчуванням
Кореневий центр сертифікації 1 IdenTrust Public Sector є довіреним за замовчуванням у стандартних сховищах довірених сертифікатів для таких операційних систем і платформ:
- Microsoft Windows;
- macOS
- iOS / iPadOS
- Android
Як результат, для кінцевих точок або систем, що використовують сховища довірених сертифікатів за замовчуванням на цих платформах, не потрібні жодні дії клієнта, якщо сховище довірених сертифікатів не було явно змінено або обмежено політикою клієнта.
Примітка до сховища довірених даних Android
Кореневий центр сертифікації IdenTrust Public Sector CA 1 включено до сховища центрів сертифікації системи Android і за замовчуванням є довіреним у підтримуваних наразі версіях Android. Android не надає публічного, специфічного для версії зіставлення дат впровадження окремих кореневих сертифікатів. Довіра керується через магазин сертифікації CA системи Android та розповсюджується через оновлення операційної системи та оновлення системи Google Play.
Клієнту не потрібні жодні дії, окрім випадків, коли сховище довірених сертифікатів системи Android було явно змінено політикою пристрою, засобами керування підприємством або обмеженнями довіри для певних програм.
Рекомендації щодо доступу до браузера (Google Chrome)
Кореневий центр сертифікації 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 та явно позначити його як довірений:
-
Імпортуйте сертифікат у Системну в'язку ключів (рекомендовано) або В'язку ключів входу
-
Відкрийте сертифікат та встановіть:
-
Під час використання цього сертифіката: Завжди довіряй
(або, як мінімум, SSL: Завжди довіряй)
-
Після того, як сертифікат буде визнано надійним на рівні системи або користувача, Google Chrome вважатиме його надійним.
Адміністратори можуть перевірити, яким сертифікатам платформи довіряє Chrome, перейшовши за посиланням: chrome://certificate-manager/localcerts/platformcerts
Для отримання додаткової інформації див. Найчастіші запитання Google.
Міркування щодо інтеграції зі сторонніми розробниками
Інтеграції зі сторонніми розробниками вимагають первинної перевірки клієнтом.
Для будь-яких сторонніх програм або служб, які встановлюють TLS/mTLS Під час підключення до програм UC для виділених екземплярів клієнти повинні виконати дії, зазначені в Зміни сертифікатів публічного центру сертифікації, що впливають на виділений екземпляр.
Вам потрібно буде безпосередньо співпрацювати зі стороннім постачальником або ІТ-адміністратором, якщо потрібні оновлення сховища довірених сертифікатів. Зміни до сховищ довірених сертифікатів третіх сторін або поведінки перевірки сертифікатів не входять до обов'язків Cisco, і Cisco не може допомагати з налаштуванням довірених сертифікатів третіх сторін або усуненням несправностей.
Додатковий тест на перевірку
Клієнти можуть перевірити підключення та довіру до нового публічного кореневого центру сертифікації, отримавши доступ до наступного тестового сертифіката IdenTrust.
Якщо цей сертифікат успішно відкривається без попереджень про довіру, кореневий центр сертифікації IdenTrust Public Sector Root CA 1 вже є довіреним у середовищі.
Підтримка
Якщо у вас є запитання щодо цієї зміни, політики браузера Google Chrome або оновлень сертифікатів у виділеному екземплярі, відкрийте запит на обслуговування в Центрі керування в розділі життєвий цикл програми UC.
Додаткові міркування для клієнтів UCM Cloud (UCMC)
Клієнти UCM Cloud (UCMC), які володіють власним доменом і самостійно керують оновленням сертифікатів UC-застосунків, і які не делегували Cisco повноваження щодо домену для підписання сертифікатів UC-застосунків, будуть відповідальні за безпосередню співпрацю з обраними ними публічними центрами сертифікації для врегулювання цієї зміни.
Цим клієнтам також слід дотримуватися рекомендацій щодо відповідного продукту UC ( продукти Cisco для локальних викликів та Cisco Expressway) щодо використання сертифікатів та виправлення помилок, пов’язаних із майбутніми змінами політики публічного центру сертифікації та браузера. Для отримання додаткової інформації див. Ролі та обов’язки.
Cisco продовжуватиме надавати оновлення, коли стане доступною підтримка окремих сертифікатів сервера та клієнта в застосунках UC. Зверніться до цього документа для отримання останніх оновлень.