Сайт может работать по HTTPS сегодня и потерять сертификат через несколько недель, если автоматическое продление сломалось. Проверять нужно не только срок действия, но и путь подтверждения домена, выбранный ACME-клиент и применение нового сертификата веб-сервером. Эта инструкция разбирает HTTP-01, когда клиент размещает проверочный файл по HTTP.
Фото обложки: No machine-readable author provided. Wilweterings assumed (based on copyright claims).; Datacenter.jpg, Public domain. Уменьшение размеров и преобразование в WebP; кадрирование не выполнялось. Тематический снимок не изображает инфраструктуру упомянутых провайдеров.
Установите владельца автоматизации
Сертификат может обслуживать панель, Certbot, другой ACME-клиент или внешний прокси. Не устанавливайте второй клиент поверх существующей схемы. Два независимых процесса могут хранить разные файлы, спорить за challenge и обновлять сертификат, который веб-сервер вообще не использует.
Зафиксируйте домены сертификата, фактическую дату окончания и путь подключения в серверной конфигурации. Секретный приватный ключ не включают в отчёт. Если TLS завершается на CDN, отдельно проверьте внешний сертификат и соединение до origin: они могут иметь разные сроки и процедуры.
Как проходит HTTP-01
Let’s Encrypt запрашивает специальный файл в /.well-known/acme-challenge/ по HTTP на порту 80. При нескольких обслуживающих узлах файл должен быть доступен на нужных маршрутах. HTTP-01 не используется для wildcard: для такого сертификата требуется другой подход, обычно DNS-01.
| Этап | Что может сломаться | Проверка |
|---|---|---|
| DNS | Старый A или неисправный AAAA | Сравнить оба семейства и назначение домена |
| Порт 80 | Недоступен из внешней сети | Проверить правила и входящий маршрут |
| Challenge path | Авторизация, rewrite или чужой webroot | Контрольный файл по точному пути |
| ACME-клиент | Неверный plugin или окружение | Журнал штатного задания |
| Применение | Новый файл не подключён веб-сервером | Проверить выдаваемый сертификат после применения |
Шаг 1. Прочитайте результат последнего задания
Найдите штатное расписание клиента и журнал недавней попытки. Отличайте отсутствие запуска от неудачного подтверждения домена. В первом случае проверяют timer/cron и окружение, во втором — конкретную ACME-ошибку и маршрут challenge.
Не запускайте повторную боевую выдачу много раз подряд. Ограничения центра сертификации и временные блокировки усложнят диагностику. Сначала используйте предусмотренный клиентом тестовый режим и устраните установленную причину.
Шаг 2. Сверьте DNS без изменения зоны
Проверьте A и AAAA и сравните их с инфраструктурой, на которой клиент размещает токен. Наличие правильного IPv4 не отменяет неисправный IPv6. Если домен обслуживает несколько серверов, определите, как challenge попадает на каждый узел или на общий проверочный маршрут.
Уменьшение TTL после сбоя не очищает уже существующие кеши. Сохраните ответы авторитетных серверов и независимых резолверов. При DNSSEC отдельно разберите SERVFAIL; сетевой доступ к origin не исправляет нарушенную цепочку доверия DNS.
Шаг 3. Проверьте webroot
В согласованном каталоге создайте безопасный контрольный файл с уникальным несекретным содержимым. Откройте его через точный HTTP URL challenge-каталога. Убедитесь, что ответ содержит именно маркер, а не главную WordPress, заглушку или форму входа. После проверки удалите только созданный контрольный файл.
Правила SPA fallback, общая авторизация staging и перенаправления могут мешать проверке. Не отключайте защиту всего сайта. Если нужен отдельный открытый маршрут challenge, настройте его минимально по руководству используемого сервера и клиента. Проверьте, что исключение не открывает соседние закрытые каталоги.
Шаг 4. Выполните тест клиента
# Только если действующий клиент — Certbot # Сначала проверьте версию и штатную конфигурацию certbot certificates certbot renew --dry-run
Dry-run обращается к тестовой инфраструктуре и может выполнять проверочные hooks. Поэтому это не просто чтение файла: сначала изучите конфигурацию и выполняемые действия. Пример не является командой для произвольной панели хостинга. На управляемом сервере используйте предусмотренную провайдером процедуру.
Для Certbot сверяйте доступные параметры по установленной версии и официальному руководству. Если клиент использует DNS-01, проверяйте разрешения DNS API и публикацию TXT, а не пытайтесь лечить его открытием порта 80. Секреты DNS API хранятся отдельно с минимально необходимыми правами.
Шаг 5. Проверьте сертификат, который получает посетитель
Успешное продление файла не доказывает, что веб-сервер начал его выдавать. Сверьте имя, срок и цепочку внешнего HTTPS-соединения. При нескольких узлах проверьте каждый применимый маршрут, сохранив корректный SNI. Одиночный запрос может попасть только на уже обновлённый backend.
Не добавляйте отключение проверки TLS ради «зелёного» результата. Ошибка имени или цепочки должна остаться видимой. После изменения конфигурации сначала нужна проверка синтаксиса, затем штатное применение с согласованным возвратом.
Мониторинг результата
Контролируйте не только срок сертификата, но и успешность задания. Оповещение об ошибке продления должно приходить достаточно рано, чтобы осталось время исправить DNS или маршрутизацию. Укажите владельца уведомления и запасной канал, если основная почта зависит от того же домена.
FAQ
Нужно открыть любой произвольный порт?
Для HTTP-01 используется порт 80. Другой тип challenge имеет другие условия.
Рабочий HTTPS доказывает исправность продления?
Нет. Текущий сертификат может ещё действовать при сломанном следующем цикле.
Можно поставить ещё один ACME-клиент?
Сначала определите действующего владельца автоматизации. Дублирование без миграционного плана создаёт конфликтующие настройки.
Вывод
Полная приёмка включает успешную проверку домена, тест штатного клиента и выдачу нового сертификата посетителю. Сохраните причину сбоя и наблюдение следующего автоматического запуска.

Для смежных задач: Как настроить SSL-сертификат и HTTPS на WordPress, Подключение домена и SSL на Beget, DNS для сайта и почты: A, AAAA, CNAME, MX, TXT и проверка изменений.
Источник технических параметров: официальная документация. Проверено 29.10.2026. Диагностический протокол — редакционная рекомендация; команды не выполнялись на сервере HOSTIO.

