Пользовательский домен завис на проверке SSL

Вы добавили запись. dig её показывает. Платформа по-прежнему сообщает, что проверка ожидает завершения, и делает это уже час. Ситуация, когда пользовательский домен завис на проверке, особенно раздражает именно потому, что все доступные вам проверки вроде бы проходят успешно.

Причины сводятся к четырём механическим факторам, и приведённый ниже порядок помогает найти проблему быстрее всего.

Сначала: что именно происходит во время проверки

Прежде чем центр сертификации выпустит сертификат, он должен убедиться, что вы контролируете доменное имя. Есть два распространённых способа, и используемый платформой способ определяет, что именно может ему помешать:

• HTTP-01 — CA запрашивает http://your-domain/.well-known/acme-challenge/<token> и ожидает определённую строку. Для этого обычные HTTP-запросы к вашему домену должны доходить до платформы.
• DNS-01 — CA ищет TXT-запись. Для этого запись должна существовать и быть видимой резолверу CA, который не обязательно совпадает с тем, к которому обращались вы.

Почти всегда проверке мешает что-то, находящееся между CA и одним из этих двух элементов.

Причина 1: прокси перед challenge

Это самая распространённая причина, когда домен находится за CDN. Она действительно сбивает с толку, потому что прокси обычно и нужен именно для этой инфраструктуры.

Если ваша DNS-запись проходит через прокси, а не указывает напрямую на платформу, HTTP-01-запрос CA завершается на прокси. Прокси отдаёт собственный сертификат, применяет собственные правила и может вернуть redirect, страницу проверки или 404 — но ни один из этих ответов не содержит token, который ожидает CA.

Разрешите challenge пройти напрямую:

• Отключите прокси (переведите запись в режим grey-cloud) до выпуска сертификата, а затем включите его снова.
• Либо исключите /.well-known/acme-challenge/* из всех redirect-правил и правил доступа.

Проблема в том, что защиты вроде "Always Use HTTPS" и "Under Attack" одинаково ломают HTTP-01, хотя в браузере сайт выглядит полностью работоспособным.

Причина 2: неправильный тип записи

В большинстве остальных случаев виновата одна из двух ошибок:

A-запись указывает на адрес, который меняется. Если платформа предоставила вам hostname, используйте CNAME. Копирование текущего IP-адреса в A-запись работает ровно до тех пор, пока адрес не изменится.

CNAME на apex домена. example.com не может по стандарту содержать CNAME одновременно с записями SOA и NS. Некоторые провайдеры предлагают ALIAS, ANAME или "CNAME flattening" в качестве обходного решения, некоторые — нет. Если ваш провайдер не поддерживает такие возможности, используйте subdomain — app.example.com — и настройте redirect с apex.

# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A

Если обе команды возвращают пустой результат, остальные пункты пока не имеют значения.

Причина 3: пропагация, которую вы не проверяете

dig без аргументов обращается к вашему резолверу. Он мог закешировать только что созданный ответ — или, что ещё хуже, NXDOMAIN, полученный до создания записи. Отрицательная запись в кеше с большим TTL — действительно распространённая причина, по которой проверка не проходит час, а затем внезапно завершается без какого-либо вмешательства.

Запросите authoritative-серверы напрямую, а также публичный резолвер, чтобы понять, что, скорее всего, увидит CA:

# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Если authoritative-ответ правильный, а публичные резолверы возвращают неверный, остаётся ждать истечения TTL — исправлять здесь нечего.

Причина 4: CAA запрещает выпуск сертификата

Эта причина встречается редко, не видна при обычных DNS-проверках и никак себя не проявляет, когда проблема возникает.

Запись CAA для домена определяет, каким центрам сертификации разрешено выпускать для него сертификаты. Если такая запись есть — часто она остаётся от старой конфигурации или появляется по рекомендации security scan — и в ней не указан CA, используемый вашей платформой, выпуск завершается ошибкой. Узнать об этом можно только из логов CA, к которым у вас нет доступа.

dig +short example.com CAA
dig +short app.example.com CAA

Пустой результат означает отсутствие ограничений, и это нормально. Если записи найдены, добавьте CA, используемый вашей платформой, или удалите ограничение.

Порядок, который помогает найти проблему быстрее всего

1. Выполните dig для записи через публичный резолвер. Если ответа нет, запись настроена неправильно или ещё не распространилась — остановитесь на этом шаге.
2. Проверьте, проходит ли запись через прокси. Если да, отключите прокси или исключите ACME-путь.
3. Проверьте CAA и для apex, и для subdomain.
4. И только после этого предполагайте, что проблема на стороне платформы.

Девяносто процентов зависших проверок заканчиваются на первом или втором шаге.

Как это работает в Dockup

Два проектных решения снимают большую часть неопределённости.

DNS-запись создаётся автоматически. Если ваша зона находится в Cloudflare и вы подключили аккаунт, при добавлении домена запись создаётся автоматически — вам не нужно вручную копировать значение:

dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare

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

Доступ предоставляется через два разрешения. Zone:Read и DNS:Edit — и ничего больше. Dockup не может читать другие ваши зоны, изменять настройки аккаунта или взаимодействовать с объектами, к которым ему не предоставили доступ. Подключение автоматизации DNS не должно требовать передачи аккаунта целиком.

Состояния проверки и сертификата отображаются отдельно для каждого домена, а не в виде одного общего статуса. Поэтому сообщение "DNS verified but TLS pending" отражает реальное положение дел: это два отдельных шага, один из которых уже завершён.

Часто задаваемые вопросы

Сколько обычно занимает выпуск сертификата? Обычно меньше минуты после того, как DNS начинает корректно разрешаться. Если статус ожидает завершения более пятнадцати минут, скорее всего, что-то блокирует выпуск, а не просто замедляет его.

Почему домен открывается в браузере, но не проходит проверку? Потому что браузер следует redirect и использует HTTPS, а challenge не делает ни того ни другого. Прокси может идеально обслуживать ваш сайт и одновременно перехватывать обычный HTTP-запрос ACME.

Можно ли использовать CNAME для корневого домена? В стандартном DNS — нет. Используйте возможность провайдера вроде ALIAS или CNAME flattening либо укажите для apex subdomain с redirect.

Что такое запись CAA и нужна ли она мне? Она ограничивает список центров сертификации, которым разрешено выпускать сертификаты для вашего домена. Она не обязательна, но если такая запись есть и в ней не указан CA вашей платформы, выпуск завершится без видимой ошибки.