ACME challenges: DNS-01 vs HTTP-01 vs TLS-ALPN-01 для CDN, wildcard и закрытого порта 80

Зачем вообще нужны разные ACME-челленджи

ACME — протокол, через который клиент (Certbot, acme.sh, lego и т.п.) доказывает центру сертификации (CA), что вы контролируете домен. Доказательство делается через «челлендж» (challenge): CA просит разместить токен определённым способом и затем проверяет его доступность.

У большинства ACME-совместимых CA (включая Let’s Encrypt) в повседневной работе встречаются три метода: http-01, dns-01 и tls-alpn-01. Выбор метода влияет не только на «получится/не получится», но и на архитектуру: нужен ли порт 80, как поведёт себя CDN, где будет точка ответственности (reverse proxy или отдельный агент), и насколько предсказуемым будет продление.

Ниже — практическое сравнение: требования, грабли, типовые сценарии и быстрые правила выбора.

HTTP-01: просто и привычно, но требует работающий путь по 80

Как работает http-01

CA делает HTTP-запрос на заранее заданный путь и ожидает получить тело ответа с токеном:

http://example.com/.well-known/acme-challenge/<TOKEN>

Ключевой момент: проверка идёт по HTTP, значит CA должен достучаться до вашего домена по TCP-порту 80.

Требования и ограничения

• Порт 80 должен быть доступен извне до того места, где ACME-клиент отдаёт токен (веб-сервер, reverse proxy, встроенный ACME-эндпоинт).
• Wildcard-сертификаты через http-01 не выдаются. Для *.example.com практически всегда нужен dns-01.
• CDN/WAF/бот-защита/редиректы часто вмешиваются: CA идёт в публичный фронт, а не «туда, куда вам удобно».
• Роутинг должен быть стабильным: путь /.well-known/acme-challenge/ должен проходить без авторизации, переписывания URI и нестандартных блокировок.

HTTP-01 с CDN и reverse proxy: где ломается чаще всего

Типовая схема: домен указывает на CDN, а origin закрыт фаерволом и принимает трафик только от CDN. В момент валидации CA приходит на ваш домен, но фактически упирается в edge/CDN и его правила. Проблемы возникают, когда:

• CDN не пропускает путь /.well-known/acme-challenge/ без проверок (капча, bot protection, WAF-правила);
• включён агрессивный кеш или нормализация URL (а токен ожидается «как есть»);
• весь HTTP-трафик насильно редиректится/переписывается так, что CA не получает правильный контент;
• в режиме standalone ACME-клиент пытается занять порт 80, который уже занят Nginx/Traefik/Apache.

Практическая тактика, если всё же выбираете http-01 за CDN: заранее выделите правило «пропуск без кеша и без защиты» для /.well-known/acme-challenge/ и убедитесь, что оно работает для всех нужных хостов (включая www и альтернативные домены).

TLS-ALPN-01: когда 80 закрыт, но 443 доступен напрямую

Как работает tls-alpn-01

Здесь CA подключается по TCP 443 и проверяет TLS-рукопожатие: сервер должен поддержать ALPN-протокол acme-tls/1 и отдать специальный временный сертификат/ответ, привязанный к токену.

Проще говоря, валидация проходит «внутри TLS», без HTTP и без порта 80.

Плюсы

• Порт 80 не нужен — достаточно 443.
• Меньше зависимости от HTTP-роутинга, редиректов и правил обработки URL.
• Хорошо подходит под политику “только HTTPS”, когда вы принципиально не хотите иметь HTTP-эндпоинт даже для редиректа.

Ограничения и подводные камни

• Wildcard-сертификаты через tls-alpn-01 не выдаются — как и в http-01.
• Нужна прямая доступность 443 до компонента, который умеет ALPN-челлендж. Если между CA и вашим reverse proxy стоит “умная” прослойка (CDN/SSL-терминация/прокси), она может не пропустить или не поддержать нужный ALPN-режим.
• Не каждый reverse proxy и не каждый режим развертывания дружит с ALPN. Иногда требуется отдельная конфигурация листенера на 443 под acme-tls/1 или встроенный менеджер сертификатов.

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

Когда TLS-ALPN-01 реально выигрывает

Самый практичный кейс — порт 80 закрыт политикой безопасности, но внешний трафик на 443 разрешён и приходит прямо на ваш reverse proxy или балансер. В такой схеме tls-alpn-01 позволяет автоматизировать выпуск без «временного открытия» HTTP и без исключений в правилах.

Если же домен проксируется через CDN, чаще всего tls-alpn-01 становится неудобным: CA общается с edge, а не с вашим origin, и вы не можете заставить CDN корректно отработать ALPN-челлендж.

DNS-01: универсально для CDN и wildcard, но требует контроля DNS

Как работает dns-01

CA просит создать TXT-запись в DNS:

_acme-challenge.example.com  TXT  "<TOKEN>"

После этого CA проверяет DNS и принимает доказательство владения доменом. Для самой проверки не нужен ни порт 80, ни порт 443.

Главное преимущество: wildcard-сертификаты

Если вам нужен сертификат на *.example.com, то практически безальтернативный вариант — dns-01. Это полезно для:

• большого числа поддоменов и виртуальных хостов за одним reverse proxy;
• динамических окружений (preview/staging), где поддомены появляются и исчезают;
• сценариев, где вы хотите стандартизировать TLS на уровне фронтового прокси.

Если вы как раз настраиваете автоматизацию под wildcard, пригодится отдельный разбор: как автоматизировать wildcard-сертификаты через DNS-01.

DNS-01 и CDN: обычно самый спокойный путь

При CDN проблема http-01 и tls-alpn-01 в том, что CA «видит» edge, а не origin. dns-01 эту зависимость снимает: CA проверяет только DNS. Поэтому для доменов, постоянно живущих за CDN, dns-01 часто оказывается наиболее предсказуемым методом.

Минусы DNS-01: без автоматизации будет больно

Чтобы dns-01 был удобным, TXT-записи должны добавляться программно. Обычно используют:

• DNS API у провайдера;
• RFC2136 dynamic DNS (обновление зоны через TSIG), если вы управляете авторитативным DNS.

Если API или динамики нет, остаётся ручное добавление TXT при каждом продлении — на продакшне это почти всегда заканчивается просроченным сертификатом в самый неподходящий момент.

TTL, кэш и «почему CA не видит TXT»

Проблемы dns-01 чаще связаны не с самим ACME, а с DNS-распространением и кэшированием. Самые частые причины фейлов:

• TXT добавили не в ту зону или домен обслуживается не теми NS;
• проверяют «локальным резолвером», который видит запись, но авторитативные NS ещё не обновились (или наоборот);
• не выдержали паузу после добавления TXT, особенно если у провайдера обновление зон не мгновенное;
• в зоне остаются старые TXT, и становится непонятно, какой токен актуален.

Практическое правило: для стабильного DNS-01 важнее предсказуемое обновление зоны и корректная работа API, чем попытки «занизить TTL до нуля».

Если доменов много и вы хотите централизованно управлять зонами, логично заранее выбрать удобного регистратора и DNS-панель. Для этого пригодится регистрация доменов с понятными тарифами и управлением записями.

Сравнение: что выбрать под ваши ограничения

Быстрая матрица выбора

В большинстве инфраструктур выбор упирается в три вопроса: нужен ли wildcard, доступен ли порт 80, и стоит ли перед доменом CDN или промежуточная TLS-терминация.

• Нужен wildcard → почти всегда dns-01.
• Wildcard не нужен, порт 80 открыт → чаще всего http-01 (самый простой в отладке).
• Wildcard не нужен, порт 80 закрыт, но 443 доступен напрямую до вашего прокси → tls-alpn-01.
• Есть CDN и вы не хотите обходить его на время выпуска → чаще всего dns-01.

Про reverse proxy: где держать ответственность за ACME

Заранее решите, кто именно «владеет» сертификатами:

• Reverse proxy сам выпускает и обновляет (одна точка, меньше рассинхронизации).
• Отдельный ACME-клиент выпускает, прокси подхватывает файлы (проще миграции и смена прокси без перестройки ACME-процесса).

В обоих подходах избегайте хрупких схем, где ради обновления сертификата нужно останавливать основной сервис или вручную править DNS.

Надёжность и безопасность: что важно кроме «работает сейчас»

Не создавайте временные исключения, которые забывают закрыть

http-01 часто провоцирует временно открыть порт 80, добавить «особые» правила в роутинг или ослабить WAF. После успешной валидации это иногда забывают откатить. Если у вас строгая политика «только 443», то tls-alpn-01 или dns-01 обычно чище с точки зрения эксплуатации.

DNS-01 повышает ценность секретов DNS

В dns-01 вы доказываете контроль над DNS-зоной. Это удобно, но критично по безопасности: утечка DNS API-токена или TSIG-ключа может позволить менять записи и выпускать сертификаты на ваши домены. Минимизируйте права (только нужные зоны и записи), храните секреты в защищённом хранилище, включайте ротацию и аудит.

Наблюдаемость: как узнать о проблеме до ночного падения продления

• Логи и алерты ACME-клиента на ошибки продления.
• Внешний мониторинг срока действия сертификата (проверка по домену).
• Тестовый прогон после изменений в DNS, CDN и reverse proxy (например, на staging-окружении).

Если вы активно используете SAN-сертификаты и автоматизацию, полезно помнить про лимиты и планирование обновлений: лимиты Let’s Encrypt и как не упереться в rate limits при автоматизации.

Мини-шпаргалка по диагностике

HTTP-01

• Проверьте доступность порта 80 извне (фаервол, security group, NAT).
• Убедитесь, что /.well-known/acme-challenge/ отдаётся без авторизации, переписываний и нестандартных блокировок.
• Если есть CDN/WAF — убедитесь, что для этого пути нет кеша и нет bot-protection.

TLS-ALPN-01

• Проверьте, что 443 доступен напрямую до компонента, который реально отрабатывает ALPN.
• Убедитесь, что ваш reverse proxy или балансер поддерживает режим acme-tls/1 и не ломает TLS-рукопожатие.

DNS-01

• Проверьте, что TXT создаётся в правильной зоне и обслуживается правильными NS.
• Дайте время на обновление зоны у провайдера и учитывайте кеширование резолверов.
• Сведите права DNS API-токена к минимуму, достаточному для ACME.

Итог: какой челлендж выбрать под CDN, wildcard и ограничения по портам

Если нужен wildcard или домен постоянно обслуживается через CDN и вы не хотите зависеть от поведения edge и WAF, то dns-01 чаще всего самый надёжный выбор при условии нормальной автоматизации DNS.

Если нужен максимально простой выпуск без трогания DNS и порт 80 доступен — http-01 остаётся практичной «рабочей лошадкой».

Если 80 закрыт, но есть чистый доступ на 443 прямо до вашего reverse proxy — tls-alpn-01 позволяет автоматизировать выпуск без открытия HTTP, но совместимость со стеком лучше проверить заранее.

Главный критерий — предсказуемость продления в вашей реальной сети: с CDN, фаерволами, прокси и организационными процессами.