Истёк SSL-сертификат: как восстановить HTTPS на сайте

Если срок SSL-сертификата истёк, нужно восстановить действующий сертификат на том узле, который обслуживает посетителей. Успешный выпуск нового файла ещё не подтверждает исправление сайта: веб-сервер, прокси или CDN может продолжать отдавать прежний. Начните с адреса проблемной страницы и фактически показываемого сертификата. Не просите клиентов отключать проверку безопасности ради оформления заказа и не переводите вход с паролем на незашифрованное соединение как постоянное решение.

Название SSL сохранилось в обиходе, хотя современные HTTPS-соединения используют TLS. Здесь речь о восстановлении сайта после сообщения о сроке сертификата, а не о выборе его поставщика. Браузер способен предупреждать и по другим причинам. Если перепутать их, повторный выпуск может не помочь: останется неверное имя, неполная цепочка доверия или проблема времени на устройстве. Сначала сохраните точное сообщение, затем проверяйте гипотезу о продлении.

Убедитесь, что проблема именно в сроке

Откройте сведения о сертификате для конкретного адреса и посмотрите период действия. Уточните дату и время на устройстве, где наблюдается ошибка. Сохраните hostname целиком: основной домен, www и отдельный поддомен могут обслуживаться по-разному. Не подменяйте адрес главной страницей, если предупреждение возникает при переходе в кабинет. Сам факт работы одного HTTPS-адреса не описывает все узлы проекта.

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

Найдите место, где завершается HTTPS

Нарисуйте короткую цепочку: посетитель, внешний прокси или CDN, сервер приложения. Не в каждом проекте присутствуют все звенья. Важен узел, предъявляющий сертификат посетителю. Если HTTPS завершается на внешнем сервисе, обновление сертификата только внутри VPS не обязательно изменит внешний результат. И наоборот, защита связи между прокси и приложением относится к отдельному соединению, которое тоже может иметь свои настройки.

Зафиксируйте ответственного за каждый участок и доступную панель управления. Сертификат мог выпускаться хостингом, автоматическим ACME-клиентом или поставщиком платного сертификата. Не устанавливайте второй независимый механизм поверх неизвестного первого ради быстрого результата. Сначала выясните, какой способ должен поддерживать проект и где хранится его конфигурация. Иначе следующее автоматическое обновление может вернуть прежнее состояние, а команда не поймёт, кто управляет активным файлом.

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

Разделите выпуск, установку и применение

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

Если используется ACME, проверьте причину последней неудачной проверки домена. Let's Encrypt описывает разные типы подтверждения контроля: например, HTTP-01 проверяет специальный ресурс веб-сервера, а DNS-01 — TXT-запись. Это разные механизмы, и ошибка одного не лечится случайным изменением другого. Смотрите выбранный способ и журнал попытки. Публично передаваемое описание ошибки не должно содержать секреты доступа к DNS или приватный ключ сертификата.

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

Автоматизация требует проверки результата

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

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

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

Что проверить перед закрытием аварии

1. Внешний адрес отдаёт сертификат с актуальным периодом действия и подходящим именем.
2. Браузер открывает нужную страницу без прежнего предупреждения.
3. Проверены затронутые кабинет, API или другие отдельные адреса, если они входили в сбой.
4. Прикладной сценарий проходит без обхода проверки TLS и без отправки реальных платежей для теста.
5. Причина отказа продления записана, повторная автоматическая попытка предусмотрена.
6. Ответственный знает, где посмотреть результат и куда придёт уведомление.

Проверяйте именно затронутый путь пользователя. Главная может открываться, а отдельный запрос к поддомену — по-прежнему завершаться ошибкой. Если во время сбоя не работали вход или интеграция, выясните, нужны ли безопасные повторные действия. Не воспроизводите коммерческие операции вслепую: состояние первой попытки должно быть известно до повторения. Восстановление TLS и корректность данных приложения — разные части приёмки, хотя для посетителя они выглядят одним сбоем.

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