Certbot не продлевает сертификат: проверяем всю цепочку

Если Certbot не продлевает сертификат автоматически, найдите разрыв в цепочке: расписание, запуск клиента, проверка владения, выпуск и применение результата. Сначала установите, кто управляет этим сертификатом и какой плагин использует. Добавление ещё одного cron не исправит недоступную проверку домена и не докажет обновление HTTPS.

Начните с одного сертификата и его владельца

На сервере могут остаться несколько способов управления: панель, отдельный ACME-клиент, старое задание администратора. До изменений выясните, какая система отвечает за конкретный публичный вход. Название Certbot в установленном пакете ещё не подтверждает, что именно он продлевает сертификат, который получают посетители.

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

Проверка цепочки: что подтверждено на каждом шаге

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

Не считайте отсутствие нового файла ошибкой без условий

В руководстве Certbot renew описан как проверка необходимости продления с повторным использованием сохранённых параметров. Успешный выход возможен и без нового выпуска, если продление ещё не требуется. Поэтому одного кода завершения недостаточно для утверждения «сертификат обновился».

Сопоставьте поведение с установленной версией и действующим сроком. Не подставляйте старый фиксированный порог из случайной инструкции. Если сертификат ещё не нуждается в замене, расследование должно проверить готовность автоматической процедуры, а не заставлять рабочий центр выпускать новый экземпляр при каждом запуске.

Какая проверка владения должна пройти

По документации Let’s Encrypt о challenge, HTTP-01 проверяет специальный ресурс на веб-сервере через порт 80. DNS-01 использует заданное значение TXT. Значит, обычная доступность главной страницы или наличие произвольной TXT-записи не подтверждают нужный ответ проверки.

Для HTTP-пути выясните, какой узел получает обращение и где оказывается ресурс проверки. Если входов несколько, ответ должен быть доступен по нужной схеме, а не только на одном внутреннем сервере. Не открывайте дополнительные произвольные порты в надежде, что центр начнёт проверять их вместо предусмотренного метода.

Для DNS-пути установите обслуживающего провайдера зоны, способ автоматического изменения записи и наблюдаемое состояние нужного имени. Регистратор и провайдер DNS могут быть разными системами. Не заменяйте проверку применения записи ожиданием одинакового универсального количества минут для всех услуг.

Ручная проверка не всегда превращается в автоматическую

Руководство Certbot отмечает ограничение manual: автоматическое продление требует соответствующего механизма authentication hook. Если при первоначальном выпуске человек вручную добавлял запись, повторение команды без участия человека ещё не решает эту часть процесса. Проверьте, как именно должен появляться ответ следующего challenge.

Если автоматизация работает через DNS API, ограничивайте доступ необходимой областью по возможностям провайдера. Let’s Encrypt предупреждает о риске размещения полных DNS-учётных данных на веб-сервере. В поддержке серверной инфраструктуры согласуйте управление такими доступами отдельно от настройки расписания.

Что означает успешный dry run

Certbot описывает dry run как тестовый проход; он не является заменой сохранённого рабочего сертификата. Перед запуском проверьте выбранный ACME-сервер и связанные действия: дополнительные параметры и hooks могут менять поведение проверки. Не называйте её операцией, которая вообще никак не взаимодействует с обслуживающей системой.

Тест выполняет ответственный администратор в согласованной конфигурации. В статье не утверждается, что мы запускали его на чьём-либо сервере. Результат нужно сохранить вместе с областью проверки: один сертификат, выбранный метод и необходимые условия, а не общую галочку «SSL исправен».

Выпуск завершился — проверьте применение

При успешном выпуске выясните, как сертификат должен попасть в обслуживающий узел. Действие после успешного обновления и действие после любой попытки различаются; в Certbot для этого предусмотрены разные hooks. Согласуйте смысл каждого шага, не добавляя автоматический перезапуск всех сервисов.

Затем проверьте публичное соединение и остальные предусмотренные входы. Если новый результат существует, а посетитель получает прежний, это следующая задача диагностики. Сопровождение сайта должно учитывать внешний прокси и маршрут посетителя, а не только состояние файлов на исходном сервере.

Порядок ремонта и следующий цикл

1. Определите единую ответственную систему и сохранённые параметры нужного сертификата.
2. Найдите последнюю ожидаемую попытку и первую неподтверждённую границу цепочки.
3. Исправьте конкретное условие: запуск, challenge, доступ к провайдеру или применение.
4. Проведите согласованную проверку, сохранив её результат и ограничения.
5. Настройте контроль срока публичного сертификата и результата следующего автоматического цикла.

Не проводите бесконечные принудительные перевыпуски: они не заменяют диагностику и могут столкнуться с ограничениями центра. Для аудита безопасности сохраните ответственного, доступы по ролям и способ уведомления об отказе. Завершённой можно считать управляемую цепочку с проверенным результатом, а не просто ещё одно задание в планировщике.