FASTPANEL не выпускает Let’s Encrypt: проверяем A, AAAA, IPv6 и Cloudflare

Почему FASTPANEL не выпускает Let’s Encrypt и с какой проверки начинать?

Ошибка выпуска сертификата в FASTPANEL ещё не означает неисправность FASTPANEL. Панель запускает получение сертификата, но подтверждение контроля над доменом происходит извне. Если запрос приходит не на тот IP, попадает в другой virtual host или не может забрать HTTP-01 challenge, новый запуск закончится той же ошибкой.

После переноса сайта ситуация часто выглядит вполне благополучно: example.com уже открывается с нового VPS, поэтому кажется, что DNS исключён. Потом выясняется, что www.example.com остался на старом IP или у корневого домена сохранилась AAAA старого сервера. Для браузера и для заказа сертификата это разные сценарии.

Что зафиксировать из ошибки FASTPANEL перед изменением настроек

До любых изменений посмотрите, для какого hostname завершилась ошибкой проверка. Если сертификат запрашивается сразу для example.com и www.example.com, неудачная авторизация одного имени может сорвать весь заказ. Полезно также понять класс ошибки: DNS-разрешение, timeout соединения, HTTP 403/404, неправильный ответ или другая причина.

Не меняйте одновременно A, AAAA, Cloudflare Proxy и правила редиректа. Иначе сертификат может внезапно выпуститься, но вы так и не узнаете, что именно было сломано. Рабочий подход проще: одна правка, тот же тест, сравнение результата.

Для первичной картины достаточно нескольких команд:

dig A example.com
dig AAAA example.com
dig A www.example.com
dig AAAA www.example.com
curl -I http://example.com/

В Windows можно начать с nslookup:

nslookup example.com
nslookup -type=AAAA example.com

На этом этапе задача не в том, чтобы сразу починить сертификат. Нужно определить слой, на котором запрос перестаёт идти ожидаемым маршрутом.

Куда на самом деле указывают A-записи домена, www и алиасов?

FASTPANEL должен пройти проверку для каждого имени, включённого в сертификат. Правильный A у example.com не спасает, если www.example.com или другой алиас ведёт на старый сервер.

Сначала выпишите все hostname, для которых FASTPANEL пытается получить сертификат, и проверьте их по отдельности:

dig +short A example.com
dig +short AAAA example.com

dig +short A www.example.com
dig +short AAAA www.example.com
dig +short CNAME www.example.com

Если www сделан через CNAME, проверка на этом не заканчивается. Нужно посмотреть, куда ведёт CNAME и какие A/AAAA уже есть у конечного имени.

Например, после миграции можно получить такую картину:

$ dig +short A example.com
203.0.113.20

$ dig +short A www.example.com
198.51.100.15

Если новый FASTPANEL-сервер использует 203.0.113.20, а www продолжает отвечать с 198.51.100.15, причина найдена. Не нужно трогать Nginx, firewall или сертификаты на новом VPS — запрос для www туда вообще не приходит.

ping для такой диагностики недостаточен. Он может показать один адрес и подтвердить сетевую доступность, но не объяснит CNAME-цепочку, отдельную AAAA или то, какой virtual host отдаётся по HTTP.

Отдельно проверьте, какие nameserver реально обслуживают домен:

dig NS example.com

Если домен делегирован на Cloudflare, запись, изменённая у регистратора или в локальной DNS-зоне FASTPANEL, может вообще не участвовать в публичном разрешении имени. Смотрим не только на то, что записано в кабинете, а на то, что DNS реально отдаёт наружу.

Есть ли у домена AAAA и почему неправильный IPv6 срывает валидацию?

Если у hostname существуют одновременно A и AAAA, Let’s Encrypt первоначально предпочитает IPv6 для HTTP-01 проверки. Поэтому рабочий IPv4 не компенсирует неправильно настроенный IPv6. Браузер владельца сайта может открывать страницу по IPv4, а удостоверяющий центр в это время получает другой ответ по AAAA.

У IPv6→IPv4 fallback есть существенное ограничение: повторная попытка по IPv4 выполняется при сетевом timeout. Если IPv6-сервер доступен и возвращает неправильный HTTP-ответ, например 404 или чужую страницу, такая ошибка не превращается автоматически в повторную проверку по IPv4.

Как проверить AAAA и сравнить IPv4 с IPv6

dig +short AAAA example.com

curl -4 -I http://example.com/
curl -6 -I http://example.com/

Сравнивайте не только код ответа. Посмотрите Location, Server и содержимое страницы. Особенно показателен такой результат:

IPv4:
HTTP/1.1 200 OK

IPv6:
HTTP/1.1 404 Not Found

Этот результат уже многое доказывает. IPv6-адрес доступен, соединение устанавливается, HTTP-сервер отвечает. Значит, искать только в маршруте или firewall уже не нужно. Скорее всего, запрос попадает в неправильный vhost либо путь challenge не обслуживается сайтом по IPv6.

Ещё один вариант:

IPv4:
HTTP/1.1 200 OK

IPv6:
curl: (28) Connection timed out

Здесь класс ошибки другой. Теперь стоит проверить IPv6 route, firewall и доступность TCP/80. Не смешивайте эти два сценария.

Если домен находится за Cloudflare в режиме Proxied, публичная AAAA также требует отдельной интерпретации: она может относиться к сети Cloudflare, а не к IPv6 origin-сервера. В этом случае нельзя просто сравнить результат публичного dig AAAA с адресом VPS и сделать вывод, что DNS настроен неправильно.

Когда AAAA исправлять, а когда удалять

Если сайт должен работать через IPv6, правильное решение — настроить IPv6 полностью: корректная AAAA, адрес на сервере, привязка сайта, порт 80 и правильный vhost. Если IPv6 для hostname не используется, ненужную AAAA лучше удалить.

Привязан ли IPv6 к сайту в FASTPANEL?

AAAA может точно совпадать с IPv6 самого VPS, но этого недостаточно. FASTPANEL должен обслуживать нужный сайт на этом адресе. Если IPv6 существует на сервере, но не выбран для сайта, запрос способен попасть в default virtual host или в другой проект.

Проверьте карточку сайта в FASTPANEL: Настройки → Основные. В списке IP-адресов должен быть выбран IPv6, указанный для этого сайта в DNS.

Как отличить проблему IPv6 от неправильного virtual host

Сравните один и тот же hostname через два протокола:

curl -4 http://example.com/
curl -6 http://example.com/

Допустим, IPv4 возвращает страницу сайта, а IPv6 — стандартную заглушку веб-сервера. Это уже не «DNS ещё не обновился». Запрос по IPv6 дошёл до нужной машины, веб-сервер его принял, но выбрал не тот сайт.

При необходимости origin можно проверить напрямую, не меняя публичный DNS. Для IPv4:

curl --resolve example.com:80:203.0.113.20 http://example.com/

Для IPv6:

curl --resolve example.com:80:[2001:db8::20] http://example.com/

--resolve заставляет curl обратиться к указанному IP, но сохранить hostname example.com в HTTP-запросе. Это удобно при диагностике virtual host: можно проверить конкретный сервер независимо от текущего ответа DNS.

Когда по IPv4 и IPv6 один hostname отдаёт один и тот же сайт, можно переходить к следующему уровню — непосредственно к HTTP-01 challenge.

Доступен ли /.well-known/acme-challenge/ через HTTP?

Рабочая главная страница по HTTPS не подтверждает доступность HTTP-01 challenge. Let’s Encrypt должен получить специальный ресурс через HTTP на внешнем порту 80, поэтому проверять нужно именно /.well-known/acme-challenge/.

FASTPANEL предлагает для диагностики создать тестовый файл:

echo "Let's Encrypt creation test" > /usr/local/fastpanel2/web/letsencrypt/LE.txt

После этого запросите его обычным GET-запросом:

curl -4 http://example.com/.well-known/acme-challenge/LE.txt
curl -6 http://example.com/.well-known/acme-challenge/LE.txt

Ожидаемый результат:

Let's Encrypt creation test

Если вместо этой строки приходит HTML другого сайта, 403 или 404, проблема уже локализована. Соединение до веб-сервера состоялось, но challenge обслуживается неправильно.

Для просмотра заголовков и редиректов можно отдельно использовать HEAD-запрос:

curl -I http://example.com/.well-known/acme-challenge/LE.txt

Но не подменяйте им основной тест. curl -I отправляет HEAD, а реальная проверка содержимого выполняется GET-запросом. Конфигурации, где HEAD и GET обрабатываются по-разному, встречаются редко, но при диагностике лучше воспроизводить нужный тип запроса как можно точнее.

Почему challenge нужно проверять отдельно по IPv4 и IPv6

Обычный curl может выбрать только один доступный адрес и показать успешный результат. Если опубликована AAAA, выполните -4 и -6 явно. Один и тот же файл должен отдаваться корректно через каждый IP-стек, который опубликован для hostname.

Мешает ли Cloudflare выпуску Let’s Encrypt на origin-сервере?

Cloudflare не мешает Let’s Encrypt автоматически, но режим Proxied добавляет ещё один слой между удостоверяющим центром и FASTPANEL. При включённой оранжевой тучке публичный DNS возвращает адреса Cloudflare, а HTTP-запрос сначала обрабатывает Cloudflare и только затем передаёт его origin-серверу.

Поэтому при Proxied проверяются две разные цепочки: внешний маршрут через Cloudflare и сам origin. Если смешать их, легко получить ложный вывод. Например, dig A показывает «чужие» IP, хотя для Proxied это нормальное поведение.

Как проверить origin напрямую, не отключая Cloudflare

Если IP origin известен, DNS менять необязательно. Можно отправить запрос прямо на VPS с нужным Host:

curl --resolve example.com:80:203.0.113.20 \
http://example.com/.well-known/acme-challenge/LE.txt

Если origin возвращает Let's Encrypt creation test, а обычный запрос через домен — нет, FASTPANEL и vhost, скорее всего, работают. Тогда следующий кандидат — слой Cloudflare: Redirect Rules, URL Rewrite Rules, Origin Rules, WAF или другое правило, затрагивающее /.well-known/acme-challenge/.

Если прямой запрос к origin тоже возвращает 404 или чужую страницу, отключение Cloudflare проблему не исправит. Сначала чинится FASTPANEL/origin.

Когда временно переключать запись в DNS only

DNS only полезен как диагностический тест, если прямую проверку origin выполнить неудобно. После переключения DNS начинает возвращать origin IP, а HTTP идёт напрямую к VPS. Если проблема исчезла, один слой уже локализован.

Такое переключение не стоит воспринимать как постоянное «лечение Let’s Encrypt». При DNS only origin становится доступен напрямую, а функции прокси Cloudflare — WAF, кеширование и защита проксируемого трафика — перестают участвовать в этом маршруте.

Не ломают ли редиректы путь ACME challenge?

Редирект HTTP → HTTPS сам по себе не мешает HTTP-01. Let’s Encrypt умеет следовать редиректам, но цепочка ограничена: допускается до 10 переходов, используются схемы HTTP и HTTPS и порты 80 или 443. Поэтому редирект на нестандартный HTTPS-порт или длинная/зацикленная цепочка уже может сорвать проверку.

Посмотрите весь маршрут:

curl -IL http://example.com/.well-known/acme-challenge/LE.txt
curl -4 -IL http://example.com/.well-known/acme-challenge/LE.txt
curl -6 -IL http://example.com/.well-known/acme-challenge/LE.txt

Смотрите первый Location, после которого запрос уходит не туда. Например:

http://example.com/.well-known/acme-challenge/LE.txt
301 → https://example.com/.well-known/acme-challenge/LE.txt
301 → https://www.example.com/.well-known/acme-challenge/LE.txt
404

Здесь бессмысленно говорить просто «редирект работает». Нужно проверить A/AAAA для www.example.com и понять, какой сервер отвечает на последнем шаге.

Особенно неприятна комбинация редиректа и сломанного IPv6. Let’s Encrypt выполняет IPv6→IPv4 fallback только для первого запроса HTTP-01. Если первый запрос по IPv6 тайм-аутится, система может перейти на IPv4 и получить 301. На следующем URL снова будет предпочитаться IPv6, но повторного fallback уже не будет.

Поэтому конфигурация вида «AAAA не работает, но A работает и перенаправляет HTTP на HTTPS» не считается надёжной. Исправьте IPv6 или уберите ненужную AAAA.

Почему после исправления DNS ошибка ещё остаётся?

Если A или AAAA уже исправлены в панели, а внешний запрос продолжает видеть старый адрес, нужно разделить authoritative DNS и кеш recursive resolver. Фраза «DNS ещё не обновился» без этой проверки ничего не объясняет.

Authoritative DNS уже обновился или старый ответ только в кеше?

Сначала получите список authoritative nameserver:

dig NS example.com

Допустим, ответ содержит ns1.example-dns.com. Запросите запись прямо у него:

dig @ns1.example-dns.com A example.com
dig @ns1.example-dns.com AAAA example.com

Затем сравните с публичными recursive resolver:

dig @1.1.1.1 A example.com
dig @8.8.8.8 A example.com

dig @1.1.1.1 AAAA example.com
dig @8.8.8.8 AAAA example.com

Если authoritative NS уже отдаёт новый IP, а один recursive resolver ещё возвращает старый, сама DNS-зона исправлена — остаётся кеш. В выводе dig также виден TTL: по нему можно оценить, сколько времени конкретный кешированный ответ ещё может жить.

Если старый IP возвращает сам authoritative NS, ожидание не поможет. Запись исправлена не в той зоне либо изменения не применились.

При сложной делегации можно дополнительно пройти DNS-цепочку:

dig +trace example.com

Что видит сам сервер с FASTPANEL

Публичный DNS уже может быть правильным, а resolver, который использует VPS, продолжает видеть другой ответ. Проверяется отдельно:

host example.com
dig A example.com
dig AAAA example.com

Получаются три независимые точки: authoritative NS, внешний recursive resolver и resolver самого VPS. Если ответы одинаковые, перестаём списывать проблему на «распространение DNS» и идём дальше.

Когда причина уже не в DNS: порт 80, firewall и NAT

Если DNS указывает правильно, но запрос к challenge получает timeout или connection refused, HTTP до нужного приложения ещё не дошёл. Теперь проверяем, слушает ли веб-сервер порт 80 и может ли внешний клиент подключиться к нему по опубликованным адресам.

ss -lntp | grep ':80 '

Часто нормальная конфигурация показывает слушающий сокет для IPv4 и IPv6. Вид строк зависит от системы и версии утилиты, но типичный смысл такой:

LISTEN ... 0.0.0.0:80
LISTEN ... [::]:80

Если в DNS опубликована AAAA, а сервер слушает только IPv4:

LISTEN ... 0.0.0.0:80

это уже серьёзный диагностический признак. Нужно выяснить, почему веб-сервер не принимает IPv6-соединения либо почему сайт не привязан к IPv6.

Дальше сравните внешний HTTP:

curl -4 -I http://example.com/
curl -6 -I http://example.com/

404 и timeout нельзя лечить одинаково. При 404 сервер уже ответил. DNS и базовая сеть отработали, поэтому копать только firewall бессмысленно. При timeout, наоборот, настройки location для challenge пока вторичны — соединение не установлено.

Что меняется, если сервер находится за NAT

При NAT публичный A может указывать на внешний адрес маршрутизатора или инфраструктуры провайдера, а самого этого IP не будет на сетевом интерфейсе VPS. Это допустимо, если входящий TCP/80 корректно перенаправляется на FASTPANEL-сервер.

Есть ещё одна ловушка: сервер может не уметь обращаться к собственному публичному адресу изнутри сети из-за отсутствия hairpin NAT. Тогда curl http://example.com/, выполненный на самом VPS, завершается ошибкой, хотя внешний клиент открывает сайт нормально.

Поэтому при NAT сравнивайте два теста: запрос с самого сервера и запрос извне. Они проверяют разные участки маршрута.

Как проверить всю цепочку за 10 минут?

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

Минимальный набор команд выглядит так:

dig NS example.com
dig +short A example.com
dig +short AAAA example.com

curl -4 http://example.com/.well-known/acme-challenge/LE.txt
curl -6 http://example.com/.well-known/acme-challenge/LE.txt

curl -4 -IL http://example.com/.well-known/acme-challenge/LE.txt
curl -6 -IL http://example.com/.well-known/acme-challenge/LE.txt

Если один тест возвращает другой сервер, timeout, 403 или 404, повторный выпуск пока ничего не даст. Сначала исправляется найденный слой.

Что проверить, если A, AAAA и challenge уже исправны

Бывает и обратная ситуация: все hostname резолвятся правильно, тестовый файл доступен, IPv4/IPv6 согласованы, а новый заказ всё равно завершается ошибкой. Тогда не нужно снова по кругу менять A и AAAA. Вернитесь к конкретному тексту ошибки ACME/FASTPANEL.

Проверьте CAA:

dig CAA example.com

Отсутствие CAA само по себе не мешает Let’s Encrypt. Но если CAA используется для ограничения центров сертификации, записи должны разрешать выпуск Let’s Encrypt для нужного сценария.

Если DNS-запросы возвращают SERVFAIL, отдельно проверьте DNSSEC и работу authoritative nameserver. Такой сбой уже выходит за рамки обычной неправильной A/AAAA: удостоверяющий центр может не получить корректный DNS-ответ, даже когда браузер периодически открывает сайт.

Наконец, посмотрите, не сообщает ли ACME о rate limit. Постоянно нажимать выпуск при заведомо сломанном challenge — плохая диагностика: последовательные неудачные авторизации тоже ограничиваются. Сначала устраните причину, затем создавайте новый запрос.

И снова проверьте весь список SAN. Если example.com проходит тесты, а сертификат заказывается для example.com и www.example.com, второе имя всё ещё может быть единственной причиной отказа.

Как убедиться, что сертификат и продление будут работать?

Успешный выпуск сертификата ещё не завершает работу. Если во время диагностики вы выключали Cloudflare Proxy, меняли AAAA, открывали порт 80 или временно убирали редирект, после возврата production-конфигурации нужно повторить основные тесты. Иначе проблема проявится уже при автоматическом продлении.

Сначала проверьте обычный HTTPS:

curl -I https://example.com/

Затем посмотрите сертификат, который реально отдаётся клиенту с учётом SNI:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -ext subjectAltName

В выводе нужны три вещи: срок действия, наличие example.com и остальных нужных имён в Subject Alternative Name и отсутствие неожиданного сертификата другого сайта.

Если домен Proxied через Cloudflare, эта команда проверяет сертификат, который получает внешний клиент на edge Cloudflare. Чтобы проверить непосредственно FASTPANEL origin, подключитесь к origin IP с правильным SNI:

echo | openssl s_client -connect 203.0.113.20:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -ext subjectAltName

После этого снова проверьте HTTP challenge в уже восстановленной production-конфигурации:

curl -4 http://example.com/.well-known/acme-challenge/LE.txt
curl -6 http://example.com/.well-known/acme-challenge/LE.txt

Вторая команда нужна только тогда, когда для hostname действительно опубликована рабочая AAAA. Если IPv6 не используется, отсутствие AAAA — нормальный вариант. Если AAAA оставлена, IPv6 должен быть полноценным рабочим маршрутом к сайту, а не адресом «на будущее».

Если хотя бы один из этих тестов расходится, причина всё ещё находится до этапа получения сертификата. Сначала исправляется конкретный hostname, IP-стек или HTTP-маршрут. После этого повторный выпуск Let’s Encrypt в FASTPANEL уже имеет смысл.