Как проверить продление HTTPS на VPS

Чтобы HTTPS не перестал работать неожиданно, проверьте не только срок сертификата, но и всю цепочку его продления: расписание Certbot, подтверждение домена, применение нового файла и сертификат, который получает посетитель. Тестовое продление и внешний запрос дают разные доказательства; для надёжной проверки нужны оба.

Статья рассчитана на сайт с Nginx и сертификатом, которым управляет Certbot на VPS. Если TLS обслуживает CDN, панель хостинга или другой ACME-клиент, сначала определите владельца сертификата: команды Certbot на сервере могут не относиться к публичному HTTPS. После проверки Вы сможете составить понятный план обслуживания и понять, на каком этапе произошёл сбой.

Где находится сертификат, который видит посетитель

Сертификат на диске и сертификат в публичном соединении могут различаться. Nginx мог не перечитать обновлённый файл, домен мог вести на другой сервер, а внешний прокси — завершать TLS самостоятельно. Поэтому начните с карты маршрута: домен, публичная точка HTTPS, процесс, читающий сертификат, и инструмент продления.

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

Для Nginx пути сертификата и закрытого ключа задаются директивами ssl_certificate и ssl_certificate_key. Их назначение описано в документации SSL-модуля Nginx. Закрытый ключ не нужно выводить в терминал или отправлять кому-либо для проверки срока. Вам нужны метаданные сертификата, а не секретное содержимое.

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

Как проверить локальные сертификаты и расписание

Сначала прочитайте список Certbot и существующее расписание. Не создавайте второй cron или timer, пока не выяснили, как установлен клиент. Дублирующие задания усложняют диагностику и не устраняют неисправность подтверждения домена.

sudo certbot certificates
systemctl list-timers --all
sudo systemctl status certbot.timer --no-pager

Последняя команда применима только если в Вашей установке существует certbot.timer. Установка через snap или другой пакет может использовать другое имя и способ запуска. Отсутствие именно этой службы не доказывает отсутствие автоматизации. Сверьте способ установки с официальными инструкциями Certbot.

Для каждого сертификата запишите его имя в Certbot, обслуживаемые домены, срок, способ подтверждения и ответственного за обслуживание. Имя сертификата не обязательно совпадает с доменом: его нужно взять из списка. В дальнейшем это позволяет тестировать конкретный объект через cert-name и не затрагивать остальные сайты общего VPS.

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

Отделяйте срок домена от срока сертификата. Регистрация домена, оплаченный VPS и действующий TLS решают разные задачи. Уведомление о продлении домена не сообщает, что Certbot работает, а доступность IP не подтверждает, что сайт можно безопасно открыть по имени.

Что проверяет тестовое продление Certbot

Тестовое продление проверяет возможность пройти процесс выдачи без сохранения нового рабочего сертификата. Для обычной настройки Let’s Encrypt команда использует тестовую среду. Перед запуском убедитесь, что клиент установлен и обслуживает нужный сертификат.

sudo certbot renew --cert-name example.com --dry-run

Здесь example.com обозначает имя из certbot certificates. Если у Вас несколько сертификатов, сначала проверяйте один. Тест может взаимодействовать с конфигурацией веб-сервера и выполнять настроенные действия; выбирайте подходящее окно. Пользовательское поле --server меняет условия теста, поэтому не добавляйте его наугад.

Руководство Certbot по продлению описывает dry-run и повторное использование параметров получения. Не редактируйте вручную renewal-файлы без необходимости. После изменения способа подтверждения нужна отдельная проверка, что последующие автоматические запуски используют правильные параметры.

Сохраните время теста, имя сертификата и результат без секретов. Если test failed, прочитайте конкретный шаг: получение challenge, подключение к домену, ответ веб-сервера или DNS. Повторяющийся запуск той же команды без исправления причины обычно не даёт новой информации.

Успешный dry-run не меняет публичный срок и не доказывает, что Nginx применит будущий сертификат. Он также не заменяет мониторинг: между сегодняшней проверкой и следующим продлением можно изменить DNS, порт или путь сайта. Полезный результат теста формулируйте узко: текущая конфигурация смогла выполнить проверочное продление.

Почему подтверждение домена перестаёт проходить

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

Метод	Что нужно проверить	Что часто меняется
HTTP-01	Доступность challenge через публичный порт 80 и правильный сервер	DNS, firewall, редиректы, путь webroot
DNS-01	Правильную TXT-запись и работу выбранного DNS-плагина	Права API, DNS-зона, автоматизация записей
Проверка обслуживается внешней платформой	Настройку HTTPS в самой платформе	Домен проекта и условия подключения

Let’s Encrypt описывает типы challenge: HTTP-01 использует порт 80, а DNS-01 — TXT-запись. Для wildcard требуется подходящий метод, HTTP-01 для этого не подходит. Прочитайте условия своего метода, прежде чем открывать порты или выдавать новые DNS API-права.

Для webroot сверяйте каталог challenge с действующим location Nginx. После смены корня сайта старый путь может остаться в настройке продления. Проверьте отдельно, что URL challenge обслуживается снаружи; открытие главной страницы этого не подтверждает. Не отключайте все ограничения служебных файлов ради одного разрешённого ACME-маршрута.

При наличии нескольких серверов challenge должен быть доступен там, куда приходит проверка. Устаревший IPv6-маршрут или старая DNS-зона могут мешать даже при работающем IPv4. Не удаляйте AAAA просто по привычке: установите, нужен ли IPv6 проекту, и исправьте маршрут либо документированно уберите неподдерживаемый адрес.

Для DNS-01 ограничьте права учётных данных нужной задачей. Полный доступ к аккаунту регистратора повышает последствия утечки. Обновление ключа DNS API проверяйте заранее: иначе обычная смена пароля или прав может обнаружиться только при неудачном продлении.

Как убедиться, что Nginx применяет новый сертификат

Проверьте три вещи отдельно: новый файл существует, конфигурация указывает на него, публичный HTTPS действительно его выдаёт. Не заменяйте эти проверки одним сообщением об успешном Certbot. На сервере могут оставаться копии старого сертификата или отдельный TLS-прокси.

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

Для ручного применения конфигурации сначала выполните sudo nginx -t. При ошибке исправьте её, сохранив старую работающую конфигурацию. Если проверка успешна и Nginx управляется systemd, штатное перечитывание может выполняться через sudo systemctl reload nginx. Этот шаг должен соответствовать Вашей установке и не заменяет последующий внешний тест.

Откройте сайт с другого устройства или выполните внешний запрос без отключения TLS-проверки. Убедитесь, что имя совпадает, цепочка принимается и срок соответствует ожидаемому сертификату. Проверяйте основной домен и используемые поддомены. Внешний прокси может показывать свой сертификат; в таком случае отдельно контролируйте соединение между ним и origin.

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

Что делать, если сертификат уже истёк

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

Исправьте установленную причину: DNS, доступ к challenge, путь webroot или права DNS-плагина. После успешного теста выполните штатное продление для нужного сертификата. Затем проверьте применение и публичное соединение. Если обслуживание делегировано панели, восстановление следует выполнять её средствами, не создавая конкурирующий механизм на VPS.

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

После восстановления запишите причину, исправление и следующую дату контроля. Например, «при переносе сборки сменился webroot; исправлена настройка проверки и подтверждён dry-run». Это конкретный вывод. Фраза «переустановили сертификат» не объясняет, почему следующая попытка будет успешной.

Чек-лист обслуживания HTTPS

Список сохраняет отметки в браузере, но не получает сертификат с Вашего сервера. Используйте его после реальных проверок. Не отмечайте внешний контроль только потому, что команда локально завершилась успешно.

Для регулярного контроля добавьте срок сертификата к мониторингу VPS. Выберите запас времени, в течение которого администратор действительно сможет устранить сбой, и проверьте доставку предупреждения. Если нужно разобрать обслуживание конкретного сайта, опишите его схему через Умную форму, не отправляя закрытые ключи и данные DNS API.

Ответы на частые вопросы

Нужно ли каждый раз выпускать сертификат заново

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

Почему dry-run успешен, а срок в браузере старый

Тест не сохраняет новый рабочий сертификат. Он проверяет процесс продления. Срок в браузере меняется после реального обновления и применения в точке TLS.

Можно ли закрыть порт 80 после подключения HTTPS

Зависит от challenge. Для HTTP-01 публичный порт 80 нужен при проверке. Если хотите другой режим, сначала настройте и протестируйте поддерживаемый способ продления.

Достаточно ли оплаты VPS для продления сертификата

Нет. Оплата сохраняет услугу сервера, но не проверяет задания Certbot, домен и применение сертификата. Это отдельные процессы.

Нужно ли хранить копию закрытого ключа в статье или инструкции

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

Как проверить сайт, если используется CDN

Разделите публичный TLS CDN и HTTPS до origin. У них могут быть разные сертификаты и механизмы обновления. Успех внешнего соединения не доказывает исправность внутреннего.