Кратко

  • Authorization Domain Name, или ADN, — имя, контроль над которым фактически проверяет центр сертификации; оно может быть выведено из FQDN в заявке и не совпадать с ним.
  • SC101 описывает опасное прочтение прежнего определения: сначала удалить левые метки, затем пройти по CNAME. Так управление целью псевдонима могло выглядеть как управление клиентскими поддоменами.
  • Новый раздел сначала требует выбрать метод валидации. Метод определяет, разрешены ли CNAME, удаление меток, обе операции или ни одна; если разрешены обе, CNAME обрабатывается первым.
  • До 15 ноября 2026 года v2.2.9 позволяет следовать либо текущему разделу 3.2.2.4, либо соответствующему разделу v2.2.7. Запись о выпуске должна сохранять выбранную версию и весь путь до ADN.

Актуальный документ официально оставляет старую ветвь

TLS Baseline Requirements v2.2.9 датированы 6 августа 2026 года. В таблице изменений SC101 обозначен как уточнение Authorization Domain Names. В таблице сроков 15 ноября названо датой соблюдения нового правила вывода ADN.

Переход сформулирован прямо в разделе 3.2.2.4. До указанной даты CA вправе исполнять текущий раздел или раздел 3.2.2.4 версии 2.2.7. Начиная с 15 ноября она обязана применять текущий раздел. Это не молчаливое послабление и не предположение о том, что надзор временно не станет наказывать. Старый путь встроен в новый документ как ограниченная по времени нормативная альтернатива.

Отсюда возникает проблема идентичности. Ссылка на v2.2.9 в сентябрьском отчёте точна, но не доказывает применение алгоритма SC101. Организация могла правомерно воспользоваться ссылкой v2.2.9 на старый раздел. Версия документа и ветвь, исполненная программой, должны фиксироваться отдельно.

Протокол голосования SC0101v2 показывает полное согласие участников: все 27 голосовавших издателей сертификатов поддержали предложение; Apple, Google, Microsoft и Mozilla со стороны потребителей также проголосовали за. Против и воздержавшихся не было. Запись подтверждает необходимые пороги и кворум 17. После обсуждения 12–19 июня и голосования 23–30 июня проверка интеллектуальных прав завершилась 6 августа.

Этого достаточно, чтобы доказать принятие общей нормы. Этого недостаточно, чтобы утверждать одновременное изменение кода, конфигураций, CP/CPS, тестов, резервных узлов и аудиторских выборок во всех CA.

Технический псевдоним не передаёт клиентский поддомен

Заявитель просит включить в сертификат один или несколько FQDN. CA выбирает разрешённый метод и проверяет контроль. ADN указывает имя, к которому относится такое доказательство. При определённых условиях правила позволяют получить ADN, пройдя по DNS-псевдониму или удалив левые метки.

Гибкость нужна, чтобы не повторять одинаковую проверку для каждого узла. Но она же определяет границу полномочий. Возможность обслуживать цель DNS не означает власть над всей частью пространства имён, принадлежащей клиенту.

Обоснование SC101 говорит, что старое определение смешивало описание ADN с нормативными шагами. Было неясно, выполняются ли операции по отдельности, последовательно, многократно или в ином сочетании. При одном серьёзном прочтении CA могла сначала удалить метки слева у запрошенного FQDN, а потом пройти по одному или нескольким CNAME.

Если example.com через CNAME указывает на example.org, оператор example.org контролирует цель. Это не даёт ему контроля над blog.example.com. Но если сначала отбросить blog, а потом пройти к цели, доказательство оператора цели может показаться достаточным для клиентского поддомена. Ballot приводит оператора CDN как пример стороны, способной контролировать такую цель.

Источник не сообщает о доказанной эксплуатации и не обвиняет конкретную CA или CDN. Здесь анализируется возможная граница, созданная неоднозначным текстом, а не вымышленный инцидент.

SC101 делает порядок частью доказательства

Новый раздел начинается с выбора метода валидации. Именно метод решает, можно ли использовать шаг CNAME, шаг удаления меток, оба или ни один. Методы, проверяющие технические имена с подчёркиванием, не получают автоматически тех же полномочий, что методы, работающие на самом имени.

Если обе трансформации допустимы и применяются, CA сначала проходит цепочку CNAME и только потом удаляет левые метки. Это не позволяет предварительному сокращению расширить видимую власть цели. Итоговое имя становится ADN, контроль которого доказывает выбранный метод.

Инженеру нужны полный нормативный текст и таблица методов; пересказ статьи не является алгоритмом реализации. Но он показывает состояния, которые должны быть наблюдаемы: входной FQDN, метод, разрешённые операции, увиденная цепочка CNAME, порядок удалений, ADN и использованное доказательство.

История правила тоже имеет фиксируемые версии. Ballot ссылается на точное сравнение в GitHub, а страница документов сохраняет текущие и прежние редакции. Протокол 18 июня объясняет добавленную в v2 дату для другого затронутого положения. Эти записи показывают происхождение нормы, но не ветвь конкретного запуска.

Переходная квитанция должна хранить ход решения

Лог с итогом «проверка успешна» слишком беден. Минимальная воспроизводимая запись связывает:

время выпуска + запрошенный FQDN + выбранный метод + версия/раздел BR + наблюдения и цепочка CNAME + упорядоченные удаления + выбранный ADN + идентификатор и время доказательства + версия CP/CPS + версия реализации/конфигурации + ссылка на тест или аудит + исключения

Время определяет допустимые в тот момент варианты. Пара FQDN/ADN показывает перемещение границы. Метод ограничивает преобразования. Версия различает v2.2.7 и v2.2.9. Наблюдения DNS сохраняют изменчивое состояние. CP/CPS описывает заявленную практику, а релиз и конфигурация — то, что система могла выполнить.

Квитанция должна быть связана с устойчивым идентификатором выпуска или сертификата. Хеши могут сделать замену заметной. Секреты challenge и чувствительные эксплуатационные данные не обязаны становиться открытыми; доступ и хранение остаются контролируемыми. Цель — дать уполномоченному проверяющему исторический путь, не подменяя прошлый DNS сегодняшним.

Это аналитическое предложение Daniel Kade, а не приписанная Forum скрытая обязанность. Baseline Requirements уже содержат правила записей, политики и аудита. Тезис уже: когда сама норма разрешает два алгоритма, доказательства обязаны назвать выбранный.

CP/CPS, развёртывание и один выпуск — разные слои

Certificate Policy и Certification Practice Statement публично закрепляют практику CA; RFC 3647 даёт распространённую структуру. Новая редакция может назвать дату перехода, методы и правила отката.

Но документ не исполняет код. Он может появиться раньше последнего обновлённого узла или позже внедрения. Поэтапный rollout создаёт смешанное состояние. Резервная система может хранить иную конфигурацию. Задача, начатая до срока, может повториться после него. Заявление, состояние системы и след отдельного выпуска следует соединять, а не использовать одно вместо другого.

Общая норма и политика root program не совпадают

Baseline Requirements прямо называют себя необходимыми, но недостаточными, и связывают обязательность с принятием и применением поставщиками программ relying parties. CA/Browser Forum создаёт общую основу; root programs управляют доверием в своих продуктах.

Mozilla Root Store Policy включает общие требования и сохраняет собственные, в том числе потенциально более строгие или приоритетные правила. Apple Root Program Policy показывает ещё один самостоятельный программный слой. Они нужны для границы полномочий, не для оценки их реализации SC101.

Голосование, CP/CPS, единичное исполнение валидатора и решение root program — четыре разных источника. Существующий черновик про Entrust и власть Google посвящён последнему. Эта статья остаётся на уровне исполнения: какая из двух разрешённых дериваций приняла имя?

Что остаётся неизвестным

Публичны правило и срок, но не полное состояние каждой CA. Отсутствие объявления не доказывает задержку. Общее заявление о v2.2.9 не доказывает ранний переход. Без записи по конкретному выпуску корректный статус — «версия правила не подтверждена».

Источники