Кратко

  • Редакция 02 разрешает центру сертификации сопоставлять постоянную запись с SHA-256 JWK-отпечатком любого открытого ключа, который аккаунт ACME использовал за всё время своего существования.
  • Ротация лишает старый закрытый ключ возможности аутентифицировать новые запросы, но не отзывает автоматически DNS-полномочие. Удаление TXT, окончание кэша, persistUntil и истечение авторизации происходят независимо.
  • Немедленным стопом для всего аккаунта в проекте служит его деактивация. До неё нужен полный чек: поколение ключа, DNS-наблюдение, CAA, состояние аккаунта и предел повторного использования.

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

Именно этот разрыв описывает редакция 02 ACME DNS Persistent Challenge от 20 сентября 2026 года. История Datatracker фиксирует активный Internet-Draft рабочей группы в состоянии I-D Exists. В тексте указано Standards Track, однако intended status, shepherd, Area Director и стадия IESG не назначены. Это не RFC, не Last Call и не подтверждение внедрения у конкретного УЦ.

Механизм помещает под _validation-persist значение dns-persist-01: 43-символьный SHA-256 JWK-отпечаток в base64url без заполнения и хеш, связывающий доменное имя, отпечаток и URL аккаунта ACME. RFC 7638 задаёт отпечаток, RFC 6920 — представление хешированного имени.

Сначала УЦ вычисляет значение для текущего ключа. Если совпадения нет, он перебирает сохранённые открытые ключи в обратном порядке. Разница между 01 и 02 содержит главное новое требование: поддерживающий сервер хранит отпечаток каждого использованного открытого ключа на протяжении всей жизни аккаунта. Репозиторий группы ACME показывает разработку, а не готовое внедрение.

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

Такая непрерывность оставляет остаточное полномочие. Если проверка получена при K1, а аккаунт затем перешёл на K2, K1 больше не аутентифицирует запросы. Однако авторизация остаётся привязана к действующему аккаунту. Даже при новой DNS-проверке запись K1 может совпасть с историей. Смена текущего подписанта не равна отзыву прежнего DNS-согласия.

Удаление TXT тоже не мгновенно. Рекурсивные резолверы могут отвечать до конца TTL. Проект прямо отличает TTL от окна повторного использования: первое управляет DNS-кэшем, второе — сохранённым решением УЦ. persistUntil может ограничить авторизацию, но последующее удаление или сокращение значения не уменьшает задним числом уже полученный срок.

Получаются четыре часов: текущий ключ аккаунта; авторитативная публикация вместе с кэшами; срок ACME-авторизации; предел persistUntil, зафиксированный при наблюдении. Единый индикатор «отозвано» не объясняет, когда исчезло фактическое право.

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

По умолчанию домен включён в хеш. domain_name=* позволяет использовать одно значение для нескольких доменов того же аккаунта и ключа. Это упрощает работу, но увеличивает корреляцию и радиус ущерба. В квитанции выдачи нужен точный охват идентификаторов и wildcard.

CAA остаётся отдельной проверкой. accounturi в RFC 8657 использует настоящий URL аккаунта; постоянный TXT включает URL в хеш. Совпадение не заменяет CAA, а CAA не доказывает постоянную DNS-авторизацию.

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

Предварительную настройку можно делегировать. После аутентифицированного POST-as-GET, подтвердившего valid-аккаунт, другая сторона получает публичный URL и отпечаток для создания TXT — без закрытого ключа. Это разделяет DNS-оператора и контролёра ACME, поэтому запрос, одобрение и установка должны иметь названных владельцев.

В реестрах ACME IANA на момент публикации нет dns-persist-01. Голосование SC-088v3 CA/Browser Forum показывает отраслевую поддержку постоянного TXT-метода, ограниченного аккаунтом. Оно не доказывает внедрение этого проекта и не делает два режима идентичными.

Операционный ответ — квитанция всей жизни авторизации: FQDN и область; хеш и время; авторитативное и рекурсивное наблюдения; TTL и горизонт кэша; эмитент; domain_name=*; защищённый идентификатор аккаунта; совпавшее текущее или историческое поколение ключа; статус; CAA и DNSSEC; persistUntil; истечение авторизации; заказ и выдача, использовавшие результат.

Тогда аудит различит ротацию с разрешённым историческим совпадением, удаление при живом кэше, повторное использование без новой проверки и деактивацию до выдачи. Без такой связи решение вчерашнего дня ошибочно объясняют сегодняшним DNS.

Текст ещё может измениться. Управленческая граница уже ясна: постоянная авторизация переносит власть из разовой живой проверки в управляемую историю. Ротация обслуживает её; отзыв должен попасть именно в продолжающее действовать разрешение.

Источники