Как проверить TLS-сертификат сайта и автоматическое продление

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

TLS-сертификат связывает открытый ключ с доменным именем на ограниченный срок. Браузер проверяет, входит ли запрошенное имя в сертификат, доверяет ли он центру сертификации и действует ли срок. Закрытый ключ при этом остаётся на сервере и не должен появляться в диагностическом выводе.

Проверяйте публичный домен, а не только файл на VPS

В примерах используется example.com. Замените его своим полным доменным именем без https:// и пути. Сначала запросите заголовки сайта обычным клиентом:

curl -I https://example.com

Успешный TLS и работающий веб-сервер обычно дают строку HTTP-ответа, например HTTP/2 200 или перенаправление 301. Ошибка проверки имени, доверия или срока появляется до HTTP-ответа. Не добавляйте -k: этот параметр отключает проверку сертификата и скрывает именно те проблемы, которые мы ищем.

Запускайте внешний тест с компьютера или сервиса вне VPS. Локальное обращение может пройти по другому DNS, адресу или сетевому маршруту и не показать, что получают посетители.

Посмотрите имя, издателя и срок действия

OpenSSL может получить сертификат с публичного порта 443 и вывести только понятные поля:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

s_client устанавливает TLS-соединение. Параметр -servername передаёт SNI — имя сайта, по которому Nginx выбирает виртуальный хост и сертификат. Перенаправление </dev/null завершает ввод, а вторая команда разбирает полученный сертификат.

Проверьте поля результата:

• notBefore — сертификат не должен использоваться раньше этой даты;
• notAfter — крайний срок действия;
• X509v3 Subject Alternative Name — список доменных имён;
• issuer — центр, подписавший сертификат.

Нужное имя должно присутствовать в Subject Alternative Name. Отдельно проверьте варианты с www и без него, если оба используются: сертификат и перенаправление для каждого имени могут отличаться.

Убедитесь, что цепочка доверия собирается

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

openssl s_client -connect example.com:443 -servername example.com \
  -verify_return_error -brief </dev/null

Параметр -verify_return_error завершает соединение при ошибке проверки, а -brief оставляет краткую сводку протокола, набора шифров и результата. Успешное соединение без verification error подтверждает цепочку для доверия этого компьютера.

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

Найдите сертификат, которым управляет Certbot

Если сертификаты выпускает Certbot, сначала покажите его реестр. Команда читает метаданные управляемых сертификатов и не запускает выпуск или продление:

sudo certbot certificates

Для каждого имени команда выводит домены, срок и пути к fullchain.pem и privkey.pem. Не копируйте содержимое privkey.pem и не меняйте ссылки внутри /etc/letsencrypt/live: Certbot управляет версиями в каталоге archive и обновляет ссылки при продлении.

Сопоставьте путь fullchain.pem с Nginx:

sudo nginx -T 2>/dev/null | grep -E 'server_name|ssl_certificate(_key)?'

nginx -T проверяет и печатает собранную конфигурацию, а grep оставляет имена сайтов и пути сертификатов. Закрытый ключ не выводится — только его путь. Убедитесь, что нужный server_name использует пару из того же сертификата Certbot.

Проверьте периодический запуск продления

Способ расписания зависит от установки Certbot. Для пакета с systemd сначала найдите связанные таймеры:

systemctl list-timers --all | grep -i certbot

В выводе ожидается активный timer с прошедшим и следующим запуском. Пустой результат означает, что нужно проверить способ установки: snap, пакет дистрибутива или другой ACME-клиент может использовать собственную службу либо cron. Не создавайте второе расписание, пока не выяснили, существует ли первое.

Посмотрите последние события найденной службы. Для распространённого certbot.service команда выглядит так:

sudo journalctl -u certbot.service --since '30 days ago' --no-pager

Название unit нужно взять из списка таймеров. Успешный периодический запуск может не продлевать сертификат, если срок ещё достаточен. Ищите ошибки проверки домена, DNS, порта 80, пути webroot и перезагрузки веб-сервера.

Выполните тестовое продление

Certbot умеет проверить текущую конфигурацию через тестовый центр сертификации, не заменяя рабочий сертификат:

sudo certbot renew --dry-run

Команда перебирает управляемые сертификаты и повторяет способ подтверждения домена, сохранённый при выпуске. Успех для всех имён показывает, что текущие DNS, сетевые правила, плагин и hook способны пройти тест сейчас.

--dry-run не даёт вечной гарантии. До следующего запуска может измениться DNS, закрыться порт, исчезнуть каталог webroot или сломаться hook. Поэтому тест выполняют после изменения Nginx, firewall, домена, способа установки Certbot и сценария публикации.

Не используйте --force-renewal для регулярной проверки. Он запрашивает новый рабочий сертификат и при частых повторах может упереться в ограничения центра сертификации.

Проверьте, что Nginx перечитывает новый сертификат

После настоящего продления файлы меняются, но долгоживущий процесс должен перечитать их. Certbot-плагин или deploy hook обычно выполняет reload. Самостоятельную проверку конфигурации и мягкое применение можно выполнить так:

sudo nginx -t
sudo systemctl reload nginx

Первая команда должна завершиться сообщениями syntax is ok и test is successful. Только после этого reload запускает новые рабочие процессы без разрыва уже обслуживаемых соединений. Если тест не прошёл, не выполняйте reload — исправьте указанную строку.

Затем повторите внешний запрос OpenSSL. Сравнивайте notAfter и серийный номер публичного сертификата, а не только файл на диске. При CDN или внешнем балансировщике TLS может завершаться до вашего Nginx, и продление нужно проверять на том узле, который реально отвечает посетителю.

Добавьте предупреждение до окончания срока

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

OpenSSL может вернуть ненулевой код, если сертификат закончится в течение заданного количества секунд. Например, 14 суток — это 1209600 секунд:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -checkend 1209600 -noout

Ответ Certificate will not expire и код 0 означают, что до окончания больше выбранного интервала. Ненулевой код должен отправить уведомление владельцу. Четырнадцать суток — пример порога; выберите срок, который оставляет время исправить DNS, сеть или ACME и повторить выпуск.

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

Разбирайте ошибку продления по сетевому пути

Для распространённой проверки HTTP-01 центр сертификации должен получить специальный ответ домена по TCP-порту 80. При ошибке последовательно проверьте:

1. DNS A и AAAA указывают на нужный обработчик трафика.
2. Порт 80 разрешён во внешнем firewall и UFW.
3. Nginx принимает запрос нужного server_name.
4. Каталог challenge совпадает с настройкой Certbot.
5. Перенаправление и proxy не перехватывают служебный путь.
6. После выпуска Nginx успешно перечитывает конфигурацию.

Если используется DNS-01, порт 80 не нужен, но автоматизации требуется безопасный доступ к DNS API и корректная зона. Не заменяйте один способ другим до понимания текущей конфигурации продления.

После первой настройки HTTPS такая проверка становится регулярной операцией вместе с мониторингом VPS и анализом журналов Nginx.

Первоисточники

• Certbot: продление сертификатов и dry run
• OpenSSL: s_client
• OpenSSL: x509 и проверка срока
• Let’s Encrypt: рекомендации по автоматическому продлению