📣Изменение для TLS-сертификатов - окончание эпохи Dual-EKU
В апреле 2025 года CA/Browser Forum принял бюллетень SC-081v3, он в первую очередь известен нам поэтапным сокращением сроков действия TLS-сертификатов. Кроме того, бюллетень вносит изменения в Базовые требования для TLS (TLS Baseline Requirements) - основной документ, регламентирующий выдачу TLS-сертификатов: это требование обновляет профиль сертификата для сервера, согласно которому такие сертификаты не должны содержать EKU id-kp-clientAuth.
В TLS Server Certificate Profile (раздел 7.1.2.7) поле Extended Key Usage (EKU) должно содержать строго определенный набор значений:
🔹 должен быть указан id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1).
🔹НЕ должен быть указан id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2).
Что интересно, сами по себе TLS Baseline Requirements (v 2.2.8) все еще допускают clientAuth как опцию (MAY), но это значение перекрывается более жестким требованием Chrome.
Политика Google Chrome Root Program (v 1.8) (обновлена 5 февраля 2026 года) - именно она послужила основанием для всех международных УЦ, желающих оставаться в доверенном хранилище Chrome, исключить использование clientAuth в TLS-сертификатах.
Есть два срока для поэтапного внедрения:
🔹15 июня 2026 года: все новые промежуточные CA-сертификаты, добавляемые в базу CCADB, должны содержать только EKU serverAuth.
🔹15 марта 2027 года: все выдаваемые TLS-сертификаты должны содержать только EKU serverAuth. Наличие clientAuth в таких сертификатах, выпущенных после этой даты, приведет к тому, что Chrome перестанет им доверять.
Что решили УЦ? Правильно, они решили отозвать TLS-сертификаты, выданные после 15 июня 2026, если они включают clientAuth.
✍️Об ЭП и УЦ
В апреле 2025 года CA/Browser Forum принял бюллетень SC-081v3, он в первую очередь известен нам поэтапным сокращением сроков действия TLS-сертификатов. Кроме того, бюллетень вносит изменения в Базовые требования для TLS (TLS Baseline Requirements) - основной документ, регламентирующий выдачу TLS-сертификатов: это требование обновляет профиль сертификата для сервера, согласно которому такие сертификаты не должны содержать EKU id-kp-clientAuth.
В TLS Server Certificate Profile (раздел 7.1.2.7) поле Extended Key Usage (EKU) должно содержать строго определенный набор значений:
🔹 должен быть указан id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1).
🔹НЕ должен быть указан id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2).
Что интересно, сами по себе TLS Baseline Requirements (v 2.2.8) все еще допускают clientAuth как опцию (MAY), но это значение перекрывается более жестким требованием Chrome.
Политика Google Chrome Root Program (v 1.8) (обновлена 5 февраля 2026 года) - именно она послужила основанием для всех международных УЦ, желающих оставаться в доверенном хранилище Chrome, исключить использование clientAuth в TLS-сертификатах.
Есть два срока для поэтапного внедрения:
🔹15 июня 2026 года: все новые промежуточные CA-сертификаты, добавляемые в базу CCADB, должны содержать только EKU serverAuth.
🔹15 марта 2027 года: все выдаваемые TLS-сертификаты должны содержать только EKU serverAuth. Наличие clientAuth в таких сертификатах, выпущенных после этой даты, приведет к тому, что Chrome перестанет им доверять.
Что решили УЦ? Правильно, они решили отозвать TLS-сертификаты, выданные после 15 июня 2026, если они включают clientAuth.
✍️Об ЭП и УЦ