Кратко

  • Успешная DNS-01-проверка доказывает, что конкретный ACME-аккаунт владеет своим закрытым ключом и способен показать требуемый дайджест по имени проверки, которое видит центр сертификации. Делегирование через CNAME или NS может передать эту узкую возможность стороне, не контролирующей корень зоны, приложение или коммерческий мандат.
  • Заказ, авторизация, wildcard-охват, CSR, выпуск, хранение ключа, развёртывание, наблюдение в CT и отзыв — разные состояния. Удаление TXT или доступа поставщика не закрывает их все.

Отключение, не дошедшее до DNS

Компания заблокировала поставщику вход через провайдера идентификации, удалила его секрет из CI и сняла роль в хранилище сертификатов. В реестре приложений активной интеграции не осталось. Однако родительская зона всё ещё направляла _acme-challenge.example в зону, которой управлял прежний подрядчик.

Такое делегирование исполняет реальное полномочие. Let's Encrypt указывает, что её DNS-01-резолвер может следовать CNAME или NS в другую зону. Сторона, сохранившая ключ ACME-аккаунта и контроль над конечным ответом, может получить новую задачу, вычислить нужное значение и завершить wildcard-заказ без доступа к веб-серверам.

Это модельный случай, а не утверждение об инциденте у конкретной компании или CA. Он показывает архитектурный разрыв: отзыв доступа к приложению и отзыв способности выпускать сертификаты, закреплённой в DNS, происходят на разных поверхностях.

Какие условия соединяет дайджест

В RFC 8555 TXT не является статическим паролем. ACME-сервер выдаёт токен как минимум со 128 битами энтропии. Клиент объединяет его с ключом аккаунта в key authorization, вычисляет SHA-256 и публикует base64url-дайджест по адресу _acme-challenge.<идентификатор>.

Сходятся два условия: заявитель способен подписывать запросы как ACME-аккаунт и способен сделать ожидаемое значение видимым по имени проверки. При смене токена или ключа меняется и дайджест. Скопированный старый TXT не доказывает новый заказ.

Объект authorization фиксирует решение сервера разрешить аккаунту представлять идентификатор. У состояния valid есть срок окончания; затем оно может истечь, быть деактивировано или отозвано. Поэтому в аудите полезно записывать аккаунт, authorization, идентификатор, метод, фактическое наблюдение и окно действия, а не фразу «домен проверен».

Узкая зона не означает безвредное полномочие

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

Контроль должен охватывать каждый переход CNAME и NS, аккаунт конечной авторитетной зоны, DNSSEC, TTL, ответы и время наблюдения с релевантных точек. DNSSEC способен подтвердить подлинность делегирования и данных, но не действительность договора с поставщиком. Снимок панели родительской зоны тоже не доказывает путь, который реально прошёл запрос.

Авторитетное изменение, рекурсивные кэши и наблюдение CA могут разойтись во времени. Проверка удаления должна пройти границу TTL и сравнить представления, а не завершаться в момент сохранения настройки.

Wildcard — это характеристика охвата

Для wildcard-заказа RFC 8555 возвращает authorization базового домена без *. и устанавливает wildcard: true. Имя _acme-challenge.example может выглядеть как обычная проверка базы, хотя сертификат охватывает wildcard-идентификатор. Флаг нужно хранить вместе с заказом и CSR.

Let's Encrypt описывает DNS-01 как свой способ выпускать wildcard-сертификаты. Это сведения о конкретной CA, а не универсальное правило всех ACME-серверов. RFC 9444 также задаёт необязательную модель, в которой политика сервера может принять авторизацию вышестоящего домена для сертификата поддомена. Поддержку нельзя предполагать; аудитору нужен идентификатор, который сервер фактически записал в authorization.

CSR ограничивает имена, но не назначение

Набор идентификаторов заказа ACME неизменяем. При финализации CSR обязан содержать ровно тот же набор. После проверки нельзя незаметно добавить лишний SAN. Это важное правило целостности.

Оно не определяет, кому следует хранить закрытый ключ, где допустимо установить сертификат и какую роль приложения он вправе открывать. Заказ, authorization, CSR, выпуск, хранение, установка и первое наблюдаемое TLS-соединение должны оставаться отдельными событиями со своими владельцами и отметками времени.

CAA может сузить ещё одну поверхность. RFC 8657 определяет необязательные параметры accounturi и validationmethods для issue и issuewild. Они работают, только если указанная CA последовательно их поддерживает, и не заменяют проверку домена. RFC также предупреждает, что делегированный контроль поддомена может превзойти ограничения CAA. Политическая запись не заменяет удаление делегированной способности.

Очистка DNS не отзывает сертификат

Удаление TXT завершает один ответ. Удаление CNAME или NS после схождения кэшей завершает один маршрут. Деактивация authorization или ACME-аккаунта меняет ещё одно состояние. Ни одно из этих действий само по себе не отзывает уже выпущенный сертификат.

ACME задаёт отдельный подписанный запрос на отзыв. Протокольное право отзыва может исходить от аккаунта выпуска, от аккаунта с авторизациями для всех идентификаторов сертификата либо от закрытого ключа самого сертификата. OCSP и CRL образуют отдельную поверхность статуса; важно знать, когда изменение стало видно клиентам.

Certificate Transparency делает неожиданный выпуск наблюдаемым и проверяемым. Но SCT не является обычной проверкой сертификата, а включение в журнал не аннулирует сертификат. CT создаёт сигнал; расследование, отзыв и удаление из эксплуатации остаются отдельными действиями.

Заставьте каждую границу отказать

Негативные тесты объясняют полномочия лучше зелёной панели продления. Удалите доступ к приложению, оставьте делегирование challenge и проверьте, проходит ли новый заказ. Смените ключ ACME-аккаунта, но опубликуйте дайджест от старого. Добавьте в CSR SAN, которого нет в заказе. Одновременно проверьте точное имя и wildcard. Удалите делегирование и сравните авторитетные и рекурсивные ответы до и после TTL.

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