HTTPS упал: как быстро вернуть сайт в строй и настроить автопродление

В рабочем чате появляется сообщение «Сайт не открывается, сертификат истёк», а следом — скриншот с ошибкой 502. Первый рефлекс любого администратора — выполнить команду certbot renew и перезагрузить nginx или apache. Иногда этот метод действительно спасает ситуацию, но нередко после таких действий веб-ресурс перестает отвечать совсем. Проблема заключается в том, что фраза «всё из-за сертификата» описывает две принципиально разные поломки, требующие разных подходов к лечению. В поисковых выдачах эти сценарии часто смешивают, поэтому универсальные советы вроде «просто сделай certbot renew» либо бесполезны, либо приводят к полной недоступности сервиса для пользователей.

Два сценария одной аварии: диагностика проблемы

Прежде чем вводить команды в консоль, необходимо четко определить природу сбоя. Первая ситуация — это когда процесс продления (renewal) завершился неудачей, и у вас на руках физически нет нового файла сертификата. Вторая ситуация сложнее: файл обновился успешно, но веб-сервер продолжает работать со старым ключом в оперативной памяти. Чтобы понять, какой случай ваш, выполните базовую проверку через терминал. Используйте утилиту openssl s_client -connect yourdomain.com:443 -servername yourdomain.com. Посмотрите строку Not After в выводе. Если дата уже прошла — сертификату конец, он не продлился. Если дата свежая, но браузер всё равно ругается, значит сервер отдает устаревший артефакт. Также стоит заглянуть в логи /var/log/letsencrypt/letsencrypt.log. Ошибки типа "Failed authorization procedure" указывают на проблемы с верификацией домена, тогда как отсутствие попыток обновления говорит о сломанном cron-задании systemd-таймере.

Сценарий первый: Certbot не смог получить новый файл

Если проверка показала просроченную дату, проблема кроется в процессе получения данных от центра сертификации Let's Encrypt. Самая частая причина здесь — блокировка портов файрволом или провайдером во время проверки по протоколу http-01. Удостоверьтесь, что ваш сервер доступен извне по порту 80. Если используется Cloudflare в режиме проксирования, убедитесь, что пауза защиты позволяет Let's Encrypt достучаться до вашего реального IP-адреса. Другая распространенная ловушка — нехватка места на диске. Процесс генерации ключей требует свободного пространства в директории /etc/letsencrypt. Выполните df -h и очистите старые архивные версии командой certbot delete, если лимиты превышены. Также проверьте DNS-записи: наличие CAA-записей может запрещать выпуск сертификатов определенным центрам, а некорректный SPF иногда мешает почтовым уведомлениям об ошибках автопродления приходить администратору.

Сценарий второй: Файл есть, но Nginx игнорирует изменения

Когда openssl показывает валидный срок действия, но браузеры выдают предупреждение конфиденциальности, виноват механизм загрузки конфигурации. Веб-серверы читают содержимое файлов при старте worker-процессов. Если вы просто заменили файлы в папке live, запущенные процессы продолжат использовать дескрипторы старых файлов. Простой reload может не сработать корректно в некоторых дистрибутивах Linux. Самый надежный способ заставить сервис подхватить новую цепочку доверия — это полная перечитка конфигурации без разрыва существующих соединений. Для Nginx используйте kill -HUP <pid_master>, а лучше системные инструменты: systemctl reload nginx. В случае с Apache потребуется команда systemctl reload httpd или graceful restart. Важно проверить синтаксис перед этим через nginx -t, так как опечатка в пути к ssl_certificate_key приведет к тому, что сервис вообще откажется стартовать, выдав критическую ошибку в статусе active failed.

Настройка надежного мониторинга срока годности

Ожидание уведомлений от хостера или Let's Encrypt — плохая стратегия, письма часто улетают в спам. Необходимо внедрить независимый контроль. Проще всего создать скрипт-обертку вокруг check_http плагина для Nagios/Icinga или написать простой bash-цикл, который дергает curl -vI https://yourdomain.com и парсит ответ на предмет кода 200 и отсутствия фразы verify. Более продвинутый вариант — использование протокола OSCP или CRL для проверки отзыва, хотя для обычных корпоративных сайтов достаточно контроля даты экспирации. Установите порог срабатывания алерта не на последний день, а за 14 суток до окончания. Это даст вам окно времени на ручное вмешательство, если автоматика вдруг даст сбой из-за изменений в API регистратора доменов или сетевых проблем ЦОД.

Как обезопасить автопродление раз и навсегда

Чтобы инцидент не повторился, нужно пересмотреть архитектуру управления секретами. Во-первых, никогда не полагайтесь только на встроенный таймер certbot.timer. Добавьте внешнюю систему мониторинга, которая проверяет публичный доступ к сайту каждые пять минут. Во-вторых, настройте ротацию прав доступа к папке /etc/letsencrypt/live. Часто скрипты деплоя запускаются от пользователя www-data, который не имеет прав на чтение новых приватных ключей, созданных root-юзером через certbot. Исправьте владельца командой chown root:www-data и права 640. В-третьих, рассмотрите возможность использования ACME-клиентов, которые умеют работать в режиме webroot без остановки сервера, например acme.sh. Он менее капризен к окружению, чем тяжелый Python-based Certbot, и отлично работает даже на минимальных VPS без установки лишних зависимостей.

Практические рекомендации для немедленного внедрения

Для стабилизации инфраструктуры примените следующий алгоритм:

• Проверьте актуальность сертификата внешним сканером или openssl, зафиксируйте точную причину отказа.
• Если файл отсутствует, временно включите самоподписанный сертификат, чтобы снять заглушку браузера для пользователей, пока чинится интеграция с CA.
• Убедитесь, что в crontab или systemd timer присутствует флаг --quiet, иначе ежедневный запуск будет засорять почту мегабайтами логов.
• Настройте принудительный HUP-сигнал веб-серверу сразу после успешного выполнения certbot renew через хук --deploy-hook.
• Разделяйте сертификаты staging и production сред, чтобы тесты автопродления на деве не сожгли лимиты выдачи боевых TLS-шифров.

Как проверить с помощью Perimeter: Используйте модуль TLS scanning платформы Perimeter для непрерывного аудита ваших публичных ресурсов. Система автоматически отслеживает сроки действия всех обнаруженных SSL/TLS-сертификатов, включая забытые субдомены, и предупредит об истечении задолго до появления красных экранов у клиентов. Инструмент также проверяет корректность цепочки промежуточных центров сертификации и выявляет слабые алгоритмы шифрования, которые могут стать причиной ошибок совместимости с современными браузерами.