Когда SSL-сертификат долго не выпускается или зависает на проверке домена, владелец сайта часто видит только общий статус вроде «идет проверка» или «ожидается подтверждение». Внешне сайт может еще открываться по старому сертификату, а может уже показывать предупреждение браузера. В обоих случаях важно быстро понять, где именно остановился процесс: в DNS, на сервере, в CDN, у хостинга или на стороне сервиса, который выпускает сертификат.
Ниже — практический порядок проверки без лишней теории. Он поможет не дергать настройки наугад и быстрее вернуть нормальную работу HTTPS.
Что значит «сертификат застрял на проверке домена»
Перед выпуском сертификата центр сертификации должен убедиться, что вы контролируете домен. Обычно это делается одним из технических способов: через специальный файл по HTTP, через DNS-запись или через TLS-проверку на 443 порту. Конкретный метод зависит от хостинга, панели управления, CDN или ACME-клиента.
Проблема возникает, когда проверяющая сторона не видит нужный ответ. Например, DNS-запись добавлена не в ту зону, HTTP-запрос уходит на другой сервер, редирект ломает путь проверки, а CDN отвечает вместо вашего origin-сервера. Поэтому фраза «сертификат не выпускается» сама по себе мало что объясняет: нужно понять, какой именно этап не проходит.
Почему выпуск SSL может не завершиться
DNS-записи еще не применились или добавлены не туда
При DNS-проверке обычно требуется TXT-запись. Частая ошибка — добавить ее у регистратора, хотя домен фактически обслуживается на других NS-серверах. В панели все выглядит правильно, но публичные DNS-резолверы запись не видят.
Похожая ситуация бывает после переноса DNS. Владелец меняет записи в старой зоне, а домен уже делегирован на новую. Для проверки важна не та панель, где удобно редактировать записи, а та зона, которую реально видит интернет.
HTTP-проверку закрывает редирект, авторизация или защита
Для HTTP-проверки проверяющий сервис должен открыть специальный путь на домене. Если весь сайт принудительно отправляет посетителя на другой домен, требует пароль, блокирует неизвестные User-Agent или отдает страницу заглушки, проверка может не пройти.
Особенно внимательно стоит смотреть правила вида «все запросы на HTTPS», «все запросы на www», «закрыть сайт на время разработки», «пропускать только выбранные IP». Для обычного посетителя сайт может выглядеть рабочим, но проверочный URL будет недоступен.
Домен смотрит не на тот сервер
Иногда SSL выпускается для сайта, который уже переехал, но часть DNS-записей указывает на старый сервер. Например, корневой домен открывается с нового хостинга, а www остался на старом. Если сертификат нужен для обоих имен, проверка одного имени пройдет, а второго — нет.
Такая ошибка особенно неприятна после миграции сайта, смены CDN или добавления поддомена. Владелец проверяет главную страницу, видит нормальный ответ и не замечает, что один из вариантов домена обслуживается другой инфраструктурой.
CDN или прокси отвечает не тем сертификатом
Если сайт работает через CDN, запросы посетителей сначала попадают на внешний узел, а уже потом на ваш сервер. В этом случае важно разделять два уровня: сертификат на стороне CDN для посетителя и сертификат на origin-сервере для связи между CDN и сервером.
Сбой на одном уровне не всегда означает сбой на другом. Например, CDN может показывать посетителям свой действующий сертификат, но не подключаться к origin в строгом HTTPS-режиме. Или наоборот: на сервере все настроено верно, но выпуск edge-сертификата для домена еще не завершился.
У провайдера временно задерживается выпуск
Иногда настройки на вашей стороне правильные, но выпуск сертификатов задерживается у внешнего провайдера: хостинга, CDN, панели управления или сервиса автоматического выпуска. В такой ситуации полезно не переделывать рабочую конфигурацию, а проверить статусную страницу провайдера и историю событий в панели.
Если старый сертификат ещё действует, сохраните рабочую схему, выясните причину задержки и оставшийся запас времени. Если срок истёк, согласуйте установку действующего сертификата для нужных имён и корректной цепочки либо безопасный откат к рабочей конфигурации. Не отключайте проверку TLS, не снижайте строгий режим CDN и не меняйте DNS на неподготовленный сервер ради исчезновения ошибки.
Как проверить проблему по шагам
1. Проверьте, куда реально указывает домен
Сравните записи для всех вариантов имени: корневой домен, www, нужные поддомены. Важно смотреть не только A-запись, но и CNAME, NS и TXT, если используется DNS-проверка. Если домен делегирован на внешние NS, изменения нужно делать именно там.
Практический пример: магазин переехал на новый хостинг, а www.example.ru остался CNAME на старую платформу. Сертификат для example.ru выпускается, а общий сертификат для двух имен зависает. Решение — привести оба имени к одной актуальной схеме и повторить проверку.
2. Проверьте доступность HTTP-пути и допустимость редиректов
Для HTTP-01 проверьте доступность нужного файла по пути /.well-known/acme-challenge/ на порту 80. Авторизация, WAF или заглушка не должны подменять ответ именно на этом пути. Не снимайте защиту со всего сайта: настройте узкое исключение для проверки либо используйте поддерживаемый DNS-01.
Сам редирект на HTTPS не обязательно мешает выпуску. Например, Let’s Encrypt HTTP-01 следует максимум по 10 редиректам на HTTP или HTTPS и порты 80 или 443; при переходе на HTTPS этот валидатор не проверяет действительность сертификата. Поэтому просроченный сертификат сам по себе не создаёт описанного замкнутого круга. Ошибка возможна при цикле, недоступном порте, неподдерживаемом переходе или неверном содержимом файла. У другого центра сертификации правила нужно сверять отдельно.
3. Проверьте настройки CDN отдельно от origin-сервера
Если домен подключен через CDN, посмотрите, где именно выпускается сертификат. Для посетителей важен сертификат на внешнем узле, но строгие режимы HTTPS могут дополнительно требовать корректный сертификат на origin-сервере.
Практический пример: владелец включает строгий HTTPS-режим в CDN, а на origin стоит самоподписанный или устаревший сертификат. В браузере появляется ошибка, хотя в панели CDN сертификат для домена выглядит активным. Исправлять нужно origin-сертификат и цепочку с сохранением проверки TLS, а не только edge-сертификат. Обычная внешняя проверка SSL видит публичный узел и не подтверждает сертификат на участке CDN—origin.
4. После выпуска проверьте не только факт сертификата, но и цепочку
Даже если сертификат выпущен, сайт может работать нестабильно из-за неполной цепочки, неверного имени в сертификате, старого сертификата на одном из серверов или разной конфигурации на балансировщике. Поэтому после успешного выпуска откройте сайт из внешней проверки, а не только из панели хостинга.
Для быстрой ручной диагностики можно использовать страницу проверки SSL-сертификата. Она помогает увидеть, как сайт выглядит извне, а не только в настройках сервера.
Чем опасна задержка выпуска SSL
Если старый сертификат еще действует, задержка может казаться неважной. Но проблема легко проявится позже: при истечении старого сертификата, смене IP, включении строгого HTTPS в CDN, добавлении нового поддомена или запуске рекламной кампании. Владелец узнает о сбое уже от клиента, из рекламной статистики или по падению заявок.
Для бизнеса это не только техническая ошибка. Браузерное предупреждение про небезопасное соединение снижает доверие, мешает оплате, ломает формы и может закрыть доступ к личному кабинету. Если сайт открывается у администратора из кэша, это не значит, что он нормально доступен новым посетителям.
Как мониторинг помогает заметить проблему раньше
Ручная проверка хороша как разовая диагностика, но она не защищает от сбоя ночью, в выходной или после автоматического продления сертификата. Мониторинг должен регулярно проверять сайт извне: отвечает ли домен, какой статус возвращает сервер, открывается ли HTTPS и не появилась ли ошибка сертификата.
Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если он перестал открываться. Для SSL-тем особенно важно получать уведомление не только при полном падении сайта, но и при проблемах с HTTPS, потому что посетитель воспринимает такую ошибку как недоступность сервиса.
Когда стоит подключить специалиста
Если вы не уверены, где проходит DNS, какой сервер является origin, кто выпускает сертификат и как CDN связан с хостингом, лучше не менять все настройки подряд. Сначала зафиксируйте текущие NS, DNS-записи, режим HTTPS, статус сертификата в панели и текст ошибки в браузере.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку на профессиональную поддержку через форму Web-Puls. При сложных сбоях с DNS, SSL, хостингом или сервером также можно воспользоваться контактной информацией и кратко описать ситуацию: домен, что менялось перед сбоем, какая ошибка видна пользователям и где выпускался сертификат.
Вывод
Когда SSL-сертификат застрял на проверке домена, не начинайте с хаотичного перевыпуска. Сначала проверьте, какой метод подтверждения используется, где находится актуальная DNS-зона, доступен ли проверочный путь, нет ли конфликта с CDN и корректен ли сертификат на origin-сервере. Такой порядок быстрее показывает настоящую причину и снижает риск сломать рабочие настройки.
После исправления обязательно проверьте сайт извне и настройте регулярный мониторинг HTTPS. Так вы узнаете о проблеме раньше клиентов и сможете спокойно разбираться с причиной, а не восстанавливать сайт в режиме срочной аварии.