Убедитесь, какой сертификат видит посетитель
Проверьте срок, доменные имена, издателя и цепочку сертификатов на публичном адресе. На сервере может лежать свежий файл, а прокси, CDN или другой виртуальный хост продолжает отдавать старый.
Уточните, где завершается TLS: на CDN, балансировщике или самом веб-сервере. Продлевать сертификат нужно там, где он реально используется.
Восстановите HTTPS
Исправьте причину неудачного продления: недоступный проверочный путь, неверную DNS-запись, права на файл, остановленный планировщик или лимит центра сертификации. После выпуска установите полную цепочку и безопасно перечитайте конфигурацию сервера.
Проверьте сайт снаружи, все имена в сертификате и перенаправление с HTTP. Не отключайте проверку сертификата в браузере и интеграциях: это скрывает проблему и ослабляет защиту.
Проверьте продление заранее
Настройте автоматический запуск клиента сертификатов и тестовое продление. Отдельный мониторинг должен предупреждать о приближении срока за несколько недель, даже если сама автоматизация считает задачу успешной.
Зафиксируйте владельца домена, место завершения TLS и порядок ручного восстановления. Тогда авария не будет зависеть от человека, который однажды настраивал сервер.
Проверьте все точки использования сертификата
Один домен может обслуживаться несколькими узлами, поэтому проверьте адрес с разных сетей и каждый балансировщик. Не забудьте отдельные имена для API, почты и служебных панелей: основной сайт может уже работать, пока интеграция продолжает получать ошибку TLS.
В плановом тесте убедитесь, что новый сертификат подхватывается без ручного копирования, а уведомление приходит ответственному человеку. Храните инструкцию выпуска отдельно от сервера, доступ к которому может быть ограничен во время аварии.
Нужен такой же подход для сайта или сервера? Напишите нам через форму под статьёй.
