Applies to: Сертифікати SSL

Сертифікати SSL Довідка

Ми спробували якнайкраще перекласти цю статтю. Також доступна версія англійською мовою.

Чому GoDaddy вилучає EKU ClientAuth і переходить до кореневої ієрархії R1 для випуску DV TLS?

Примітка. Якщо ви або ваші клієнти бачите помилки "ненадійного кореневого каталогу" або ланцюга сертифікатів, ознайомтеся з нашими інструкціями з усунення проблеми .

Починаючи з 15 червня 2026 року, загальнодоступні сертифікати SSL / TLS, видані для використання на сервері, більше не зможуть включати в себе розширене використання ключів «Клієнтська автентифікація» (EKU: clientAuth). Ось основні моменти, які слід зрозуміти:

  • Ця зміна є частиною оновлення кореневої програми Chrome: нові сертифікати мають містити лише EKU «Автентифікація сервера».
  • Нові загальнодоступні сертифікати, видані після цієї дати, які містять clientAuth, не будуть надійними для Chrome.
  • Ця зміна не вплине на сертифікати, видані clientAuth до 15 червня 2026 р., І вони залишатимуться чинними до закінчення терміну дії або скасування.
  • Ця зміна не впливає на сертифікати Private-CA (для внутрішнього використання) & mdash; вона стосується лише загальнодоступних сертифікатів.

Коротше кажучи: якщо ваша організація використовує загальнодоступні сертифікати TLS для автентифікації клієнта (через clientAuth EKU), вам потрібно буде вжити заходів до 15 червня 2026 року . Що стосується стандартного використання TLS веб-сайту (лише автентифікація сервера), ця зміна не потребує дії. Проте це своєчасне нагадування: перегляньте сертифікат використання, розділіть функції належним чином і переконайтеся, що ви узгоджуєтеся з новою моделлю довіри.

Спосіб застосування цієї зміни в GoDaddy

Наші поточні проміжні продукти для підпису / випуску G2 не містять жодного EKU, що робить цю ієрархію невідповідною вимогам кореневої програми Chrome. Як результат, випуск від уражених проміжних продуктів G2 повинен припинитися до цієї дати.

Замість того, щоб створювати нові проміжні продукти випуску для ланцюга G2 & mdash; термін дії яких закінчується / завершується в Google у квітні 2027 р., Ми переходимо до випуску ПВ до нашої нової ієрархії R1, щоб відповідати політичним обмеженням.

Ми змінюємо загальнодоступний ланцюжок випуску ДВ, тому нові сертифікати листів ДВ видаються з ієрархії кореневого сертифіката CA - R1 GoDaddy TLS, використовуючи проміжний сертифікат CA DV - R1v1 TLS GoDaddy, який видає сертифікати CA.godaddy.com. Це означає, що ланцюжок емітентів, представлений серверами (лист + проміжний), може відрізнятися від того, що було в деяких системах, і будь-які внутрішні засоби, які передбачають наявність певного проміжного імені або замовлення ланцюга, повинні бути оновлені, щоб прийняти новий ланцюжок R1.

Крім того, листкові сертифікати, видані за цією ієрархією, не містять EKU ClientAuth. Будь-який робочий процес, який базується на сертифікатах аркуша DV, які можна використовувати для автентифікації клієнта TLS, має перейти до відповідного профілю сертифіката / шляху PKI. Під час розгортання сертифікати продовжують працювати в браузерах, оскільки клієнти перевіряють, використовуючи необхідний шлях перехресних підписів R1 → G2, опублікований у нашому репозиторії (certs.godaddy.com).

Як сертифікати працюють у браузері під час переходу R1 (R1 → G2 cross-sign)

Оскільки ми переносимо випуск загальнодоступної DV TLS до ієрархії R1, кореневий каталог R1 все ще перебуває в процесі отримання широкого довіри / розповсюдження в браузерах та довірчих сховищах ОС. Щоб щойно видані сертифікати R1 працювали одразу в браузерах, ми використовуємо перехресний підписаний шлях довіри до кореневого каталогу G2.

На практиці лист-сертифікат видається згідно з R1 DV, що видає CA, але клієнти перевіряють його, будуючи ланцюжок до GoDaddy Клас 2 Кореневий - G2, використовуючи опублікований перехресний сертифікат R1 → G2. Відповідними артефактами в репозиторії є якір довіри G2 (gdroot-g2), перехресний сертифікат (gd_tls_root-r1-cross-g2), проміжний номер, що видає R1 DV (gd_tls_issuing_dv-r1v1), і власний корінь ієрархії (gd_tls_root-r1). ) certs.godaddy.com. Цей підхід до перехресних знаків дає змогу браузерам перевірити ланцюжок сьогодні (якір на G2), тоді як довіра R1 поширюється з часом.
r1 - g2 поперечний шлях знаку

Чому вносяться ці зміни?

Існує кілька причин відмови від сертифікатів, які підтримують і serverAuth, і clientAuth (також відомі як сертифікати зі змішаним призначенням):

  • Відділення автентифікації сервера від автентифікації клієнта сприяє спрощенню моделі довіри сертифікатів.
  • Покращена гігієна безпеки: сертифікати із занадто багатьма цілями збільшують ризик (тобто зловживання clientAuth ненавмисним чином).
  • Використання виділених ієрархій PKI для різних функцій допомагає підтримувати чіткіші межі довіри, узгоджуючись із передовими практиками PKI (інфраструктура відкритих ключів).

Які переваги цієї зміни?

  • Зниження ризику використання багатоцільових сертифікатів. Завдяки обмеженню загальнодоступних сертифікатів лише сервером serverAuth поверхня атаки зменшується, а межі довіри чіткіші.
  • Краще дотримання вимог & врядування: Організації матимуть чіткіший розділення між автентифікацією на сервері та автентифікацією на клієнті, що може забезпечити кращий аудит і керування життєвим циклом сертифікатів.
  • Покращена чіткість роботи: якщо функцію clientAuth розділити на відповідні сертифікати або інфраструктуру, простіше керувати ролями, відкликаннями, поновленнями та гарантувати, що правильний сертифікат використовується належним чином.
  • Майбутня готовність. Ця зміна відповідає зміцненню моделей довіри до PKI та браузерів і допомагає організаціям пропонувати нові моделі безпеки та автоматизацію.

На кого це не впливає?

Більшість веб-сайтів, які використовують сертифікати лише для автентифікації на сервері (тобто типовий TLS / HTTPS), не зазнають впливу. Якщо ви використовуєте сертифікат лише для захисту свого веб-сайту для користувачів, ця дія не потребує жодних дій.

На кого це впливає?

Ця зміна стосується організацій, які використовують загальнодоступні сертифікати серверів для автентифікації клієнта (також відомі як взаємні TLS / mTLS) або автентифікації між серверами, які покладаються на eAU clientAuth. Наприклад, деякі зміни можуть вплинути на деякі фінансові послуги, SaaS-сервіси або багатокористувацький API.

Що потрібно зробити

  • Якщо ви розміщені за межами GoDaddy : переконайтеся, що під час оновлення наступного сертифіката інстальовано повний пакет, наданий кінцевими точками завантаження або клієнтським інтерфейсом.
  • Якщо ви використовуєте сертифікати в будь-якому випадку, який базується на ClientAuth (mTLS) : переконайтеся, що ці робочі процеси перенесено на використання самопідписаного сертифіката або рішення приватного центру сертифікації.

Команди також повинні підтвердити, що жодна внутрішня функція або документація не передбачає, що сертифікати листів DV містять ClientAuth EKU, оскільки листкові сертифікати R1 не включатимуть їх.

Чи означає це, що всі сертифікати, видані після 15 червня 2026 р., Є недійсними?

Ні. Сертифікати, видані до 15 червня 2026 р., Які містять clientAuth, залишаються чинними (до закінчення строку дії) згідно з існуючою моделлю довіри. Зміни стосуються лише нових публічних сертифікатів, виданих після цієї дати або пізніше.

Якщо я використовую свій сертифікат лише для типового HTTPS веб-сайту (автентифікація сервера), чи потрібно мені щось робити?

Якщо ваш хостинг знаходиться за межами GoDaddy, ви все одно маєте переконатися, що пакет використовується правильно.

Що саме означає «автентифікація клієнта» в цьому контексті?

Клієнтська автентифікація - це використання сертифіката клієнтом (користувачем, пристроєм або іншим сервером) для автентифікації на сервері. Він зазвичай використовується в mTLS (взаємний TLS) або автентифікації API від сервера до сервера, коли сервер повинен перевірити сертифікат, представлений підключаючим клієнтом.

Чи можна взагалі використовувати сертифікати clientAuth?

Так, & mdash; але для загальної довіри вам знадобиться використовувати сертифікат, спеціально виданий для автентифікації клієнта (тобто виділений clientAuth EKU), або використовувати приватний центр сертифікації для внутрішніх систем. Загальнодоступні сертифікати сервера з clientAuth EKU більше не будуть вважатися надійними в Chrome, якщо вони видані після 15 червня 2026 року.

Чи застосують цю зміну інші браузери чи лише Chrome?

Правила походять від кореневої програми Chrome, але зміни в загальнодоступній екосистемі PKI часто впливають на інші браузери та довірчі магазини. Доцільно припустити ширшу застосовність, або, принаймні, відповідність у майбутньому буде мати значення на різних платформах.

Чи стосується це внутрішнього / приватного сертифікатів ЦС?

Ні & mdash; зміна стосується лише загальнодоступних сертифікатів SSL / TLS (сертифікатів, доступних для загальнодоступних кореневих сховищ). Приватна інфраструктура центру сертифікації, яка використовується для внутрішньої автентифікації клієнта, не впливає безпосередньо.

Коли ми повинні бути готовими до цієї зміни?

Цільовий графік - 27 травня 2026 р. До цієї дати відповідальні групи повинні пройти перевірку готовності (конфігурацію видачі, правильність встановлення пакета / завантаження, інструкції з інсталяції ланцюга розгортання, моніторинг та перевірку залежностей EKU), щоб розповсюдження могло тривати без перебоїв у роботі служби.

Додаткові відомості