Кратко

  • Адрес Onion v3 образован из открытого ключа идентичности сервиса, а не из DNS-делегирования; доступность сервиса и рабочая учётная запись ACME не доказывают владение этим ключом.
  • onion-csr-01 требует особую CSR с двумя nonce и подписью ключа Onion; её открытый ключ обязан отличаться от ключа финальной CSR.
  • CAA можно прочитать из зашифрованного дескриптора или принять как подписанный временный объект при finalize, поэтому аудит должен сохранить фактический выбор УЦ.

Сертификат не рассказывает, по какой ветке к нему пришли

В обычном отчёте об автоматической выдаче остаются номер заказа, статус valid и цепочка сертификатов. Для Onion этого недостаточно. Один и тот же итог может возникнуть после разных решений о доступе, CAA и раскрытии информации. RFC 9799 задаёт общий протокол, но намеренно оставляет центру сертификации выбор источника CAA. Значит, сам сертификат не может служить доказательством выбранного пути.

Сначала нужно установить корень имени. RFC 7686 исключает .onion из обычной DNS-инфраструктуры. Адрес v3 кодирует 32-байтный открытый ключ Ed25519 сервиса, контрольную сумму и версию. Тип идентификатора dns в ACME сохранён для совместимости, а не для создания отсутствующей DNS-делегации.

Поэтому dns-01 запрещён. http-01 и tls-alpn-01 разрешены с изменениями: УЦ сам подключается к Onion Service через Tor и не перекладывает соединение на Tor2Web. Эти методы не дают wildcard и проверяют точку обслуживания, а не обязательную подпись ключа идентичности.

Для прямого доказательства RFC вводит onion-csr-01. УЦ выдаёт nonce с энтропией не менее 64 бит; ответ на nonce старше 30 дней нельзя принимать. Клиент помещает исходные байты в caSigningNonce, добавляет собственный applicantSigningNonce такой же минимальной энтропии и подписывает специальную CSR приватным ключом Onion.

УЦ проверяет PKCS#10, соответствие открытого ключа адресу, подпись, точное совпадение своего nonce и энтропию nonce заявителя. Поле subject не подтверждает личность и не проверяется. Открытый ключ этой CSR должен отличаться от ключа финального запроса.

Так разделены три полномочия: ключ учётной записи подписывает ACME-сообщения, ключ Onion доказывает контроль имени, финальный ключ получает сертификат. Обычный key authorization не требуется, поскольку доказательство уже передаётся внутри запроса, подписанного учётной записью.

Перед первой веткой УЦ должен получить право чтения

При restricted discovery внутренняя часть дескриптора доступна только разрешённым клиентам. Поле authKey сообщает открытый ключ Ed25519 УЦ для доступа. Один ключ нельзя использовать для разных Onion Services; для повторной проверки того же сервиса его можно сохранить. Это ограничивает корреляцию.

УЦ вычисляет CLIENT-ID и ищет совпадающую строку auth-client. Если её нет, протокол требует предположить, что клиентская аутентификация не нужна. Новый ключ заставляет оператора переподписать и заново опубликовать дескриптор.

Время распространения не фиксировано. RFC ожидает несколько минут, признаёт изменчивость сети и рекомендует УЦ не завершать challenge раньше чем примерно через 30 минут. Ответ клиента означает готовность к попытке чтения, а не доказанный приход новой ревизии. Для разбора сбоя нужны ключ, ревизия, время публикации, рассчитанный идентификатор и первая успешная расшифровка.

Две ветки CAA, один ключ полномочий

На первой ветке записи CAA находятся во втором зашифрованном слое и используют каноническую форму RFC 8659. Поиск вверх по DNS невозможен, проверка TLD .onion запрещена, все поддомены базового адреса используют один набор.

Флаг caa-critical в первом слое сообщает о скрытой политике и запрещает выдачу до расшифровки. Он не раскрывает значения и не доказывает их применение.

На второй ветке клиент передаёт onionCAA в finalize: текст записей или null, Unix-срок и подпись Ed25519 ключа Onion. Срок не должен быть дальше восьми часов и обрабатывается как минимум 64-битным числом. Подписывается точная строка onion-caa|, десятичный срок без ведущих нулей, | и текст CAA; для null последняя часть пуста.

УЦ может принять этот набор как единственный, проигнорировать его и прочитать дескриптор либо проверить оба. Если читать дескриптор он не умеет, отсутствие объекта вызывает onionCAARequired; возможность заранее объявить требование даёт inBandOnionCAARequired.

Обе ветки сходятся в одном месте. Каталоги Tor не являются доверенной стороной. Целостность и дескриптора, и in-band объекта проверяется через идентичность Onion. Поэтому журнал должен фиксировать не адрес доставки, а конкретные проверенные байты, подпись, срок и решение УЦ.

Третья ветка — раскрытие

УЦ сам использует Tor для Onion Service. ACME-клиенту также следует идти через Tor и выбирать Onion endpoint УЦ. Прямое соединение с известным адресом УЦ может выдать наличие скрытого сервиса на машине заявителя.

Redirect http-01 в публичный DNS способен раскрыть IP или связь инфраструктуры. Такой публичный адрес УЦ не должен проверять через Tor exit из-за риска перехвата.

Публичный WebPKI-сертификат неизбежно переносит Onion-имя в Certificate Transparency. Это может быть сознательной ценой браузерного доверия, но не нейтральным результатом. Для закрытых сервисов возможны частные или самоподписанные сертификаты. Данные абонента следует минимизировать, а для сервисов, которые УЦ не должен связывать, нужны разные ACME-ключи.

Сертификат фиксирует только конец маршрута. Чтобы понять правомерность выдачи, нужны доказательство ключа, доступ УЦ, выбранная ветка CAA и отдельный журнал раскрытия. Без них успешная автоматизация делает решение менее, а не более объяснимым.

Источники