Сертификат истёк, но браузер показывает «небезопасно» — что делать?

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

О чём речь и почему я считаю это важным для сайта

Речь о том, как сертификат SSL может быть «живой» на диске, но сайт всё равно показывает «не защищённое соединение». Это не ошибка пользователя — это ошибка инфраструктуры. Я уже не первый раз вижу, как сайты с «валидным» сертификатом ломаются в самый неподходящий момент. Браузер не верит в безопасность — и это не про «маленькую иконку» в адресной строке. Это про потерю доверия, трафика, заявок и денег.

Считаю, что это важно не потому, что «хакеры» угрожают, а потому, что уязвимость — это не событие, а состояние. Просроченный сертификат — это не сбой, а предсказуемый провал. И он может быть у любого, даже если всё «настроено правильно». Главное — не полагаться на то, что «всё работает», а проверять, что видит пользователь.

Как это устроено — что тут вообще происходит

Сертификат — это не просто файл. Он загружается в процесс веб-сервера при старте. Даже если Certbot обновил его на диске, nginx или Apache продолжает работать с «старым» — пока не перезапущен. В контейнерных средах это особенно критично: процесс не знает, что файл изменился. Никаких ошибок, никаких логов — просто тишина, и сайт работает, но с устаревшим сертификатом.

Когда сертификат истекает, браузер не просто показывает предупреждение — он блокирует доступ. Форма заявки, оплата, переходы — всё останавливается. А на фоне этого система мониторинга может «работать» — просто уведомления уходят в непрочитанный ящик. И тогда кажется, что всё в порядке. На деле — всё ломается, но никто не видит.

Как понять, что это касается вашего сайта («как я это проверяю»)

Проверяю не по логам, а по внешнему виду. Запускаю команду: echo | openssl s_client -connect ваш-сайт:443 -servername ваш-сайт 2>/dev/null | openssl x509 -noout -dates. Это то, что видит браузер. Если дата выпуска не совпадает с тем, что в Certbot — проблема есть. И она не про «не хватило места» или «сломался скрипт» — она про то, что процесс не перечитал сертификат.

Проверяю, есть ли в системе хуки для автоматического перезапуска веб-сервера после обновления. Если сертификат выдан через Let’s Encrypt, а перезагрузка не настроена — риск есть. Особенно если nginx или Apache работают в контейнере. На мой взгляд, это не редкость — это стандартная уязвимость, которую не замечают, пока не увидят «не защищённое соединение».

Что с этим делать («что я делаю в таких случаях»)

Первым делом — проверяю, как работает обновление. Запускаю тестовое обновление сертификата и смотрю, что происходит в системе. Проверяю, что хук срабатывает, и что веб-сервер перезагружается. Если контейнер — проверяю, что команда docker exec nginx -s reload выполняется корректно. Проверяю конфиг перед перезагрузкой, чтобы не сломать сайт.

Потом — проверяю, куда уходят уведомления. Не «настроены ли», а «доходят ли». Проверяю, кто читает письма. Если мониторинг пишет в несуществующий ящик — это не мониторинг. Это ложная уверенность. Закрываю это сразу: перенаправляю уведомления на реальный адрес, с проверкой доставки. И да, проверяю — не просто «настроил», а «получил».