Слетел SSL-сертификат: что делать и как вернуть HTTPS

Если сайт пишет «подключение не защищено», не начинайте с отключения предупреждений браузера или многократного перевыпуска сертификата. Сначала нужно понять, где именно нарушилась цепочка HTTPS: у сертификата закончился срок, он отозван, выпущен не для того домена, не полностью установлен либо посетитель попадает на другой сервер.

В разговорной речи и поисковых запросах обычно говорят SSL-сертификат, хотя современные сайты устанавливают соединение по протоколу TLS. В этой инструкции термин SSL используется в привычном смысле. Задача проверки — вернуть доверенное TLS-соединение без передачи приватного ключа посторонним и без рискованных изменений в работающей инфраструктуре.

Что означает «слетел SSL»

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

• закончился срок действия или сертификат ещё не вступил в силу;

• сертификат отозван удостоверяющим центром;

• сервер, CDN или балансировщик отдаёт старый либо чужой сертификат;

• имя открытого домена отсутствует в SAN: например, защищён example.com, но не www.example.com;

• сервер не передаёт промежуточный сертификат, поэтому цепочка до доверенного корня не строится;

• SNI или virtual host направляет запрос в неправильную конфигурацию;

• HTTPS уже работает, но страница загружает часть ресурсов по HTTP — это mixed content.

Важно определить точку завершения TLS. Соединение может заканчиваться не на origin-сервере, а на CDN, reverse proxy, ingress или внешнем балансировщике. Тогда сертификат на origin может быть исправен, но посетитель всё равно увидит ошибку edge certificate — или наоборот.

Что сделать в первые 10 минут

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

• Не вводите на проблемной странице пароль, платёжные и персональные данные.

• Не нажимайте «всё равно перейти», если не уверены в причине и подлинности ресурса.

• Не отправляйте исполнителю приватный ключ: для первичной диагностики он не нужен.

• Не удаляйте действующие файлы сертификата и renewal-конфигурацию до backup.

• Не запускайте подряд force-renewal: повторные неудачные запросы осложняют разбор и могут упереться в rate limits.

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

Диагностическая таблица: что означает код браузера

Формулировки отличаются между браузерами, но код обычно сужает круг причин. Таблица не заменяет проверку цепочки снаружи: один клиент может доверять локально установленному корню, а другой — нет.

Основные технические причины SSL-ошибки

Автоматическое продление Let’s Encrypt часто ломается не на выпуске как таковом, а на проверке контроля домена. Для HTTP-01 внешний центр должен получить challenge по порту 80. Закрытый firewall, неверный webroot, принудительный редирект в несуществующий upstream или проксирование через CDN могут помешать проверке. Для DNS-01 важны права API, правильная TXT-запись и время её распространения.

Проверьте DNS целиком. Устаревшая A-запись может вести часть посетителей на старый сервер, а забытая AAAA — отправлять клиентов по IPv6 туда, где сертификат не обновлялся. CAA-запись способна запретить выбранному удостоверяющему центру выпуск. Ошибки авторизации и повторные заказы могут попасть под ограничения центра, поэтому сначала исправляют причину, а не создают новые заявки по кругу.

После успешного выпуска проблема может остаться на доставке. Nginx должен использовать подходящие certificate/key и полный fullchain, а конфигурация — пройти проверку до reload. На CDN, reverse proxy и балансировщике сертификаты обновляются отдельно. Edge certificate видит посетитель, origin certificate защищает внутреннее плечо до сервера; это разные объекты с разными сроками и правилами доверия.

Неполный fullchain особенно коварен: браузер администратора может достроить промежуточное звено из локального кэша, тогда как новое устройство или поисковый робот получит ошибку доверия. Поэтому проверяют не только сам leaf-сертификат и совпадение ключа, но и порядок промежуточных сертификатов, который сервер отправляет каждому внешнему клиенту.

Частый сценарий: новые файлы уже лежат на диске, но веб-сервер продолжает держать прежний сертификат, потому что reload не выполнен или завершился ошибкой. Другой вариант — неверный SNI/virtual host: запрос конкретного домена попадает в default server и получает сертификат соседнего сайта.

Что изменилось в России и как выбирать сертификат

В 2026 году сообщалось об отзыве отдельных сертификатов, ранее выпущенных иностранным удостоверяющим центром для части российских компаний. Это не означает остановку всех иностранных сертификатов в России и не доказывает, что любая SSL-ошибка связана с отзывом. Срок, статус, издателя, серийный номер и фактическую цепочку конкретного домена всё равно нужно проверять отдельно.

Российские TLS-сертификаты доступны, но их корневые центры по умолчанию поддерживаются не каждым браузером, операционной системой, WebView и внешним клиентом. Установка российских корневых сертификатов на устройства посетителей не должна подаваться как единственное решение для публичного коммерческого сайта. Выбор зависит от географии аудитории, используемых браузеров, мобильных приложений, корпоративных окружений и схемы CDN/origin.

Одновременно жизненный цикл публичных TLS-сертификатов в мировой Web PKI становится короче. Для сертификатов, выпущенных с 15 марта 2026 года, максимальный срок сокращён до 200 дней; с 15 марта 2027 года — до 100 дней; с 15 марта 2029 года — до 47 дней. Это усиливает ценность автоматизации и мониторинга. Let’s Encrypt обычно выпускает сертификаты на 90 дней и рассчитывает на автоматическое продление, а не на ручное действие владельца в последний день.

Что владелец может проверить самостоятельно

Откройте сведения о сертификате в браузере и выпишите издателя, срок notBefore/notAfter, серийный номер и список Subject Alternative Names. Убедитесь, что там есть именно тот адрес, который открывает пользователь. Сравните apex-домен и www, другую сеть и другой браузер. Если результаты различаются, зафиксируйте различия — они часто указывают на DNS, IPv6, CDN или локальное доверенное хранилище.

Проверьте A, AAAA, CNAME и CAA в панели DNS, а в панели CDN — активный edge certificate и режим соединения с origin. Не меняйте записи наугад: сначала сохраните значения и TTL. Для внешней первичной оценки можно использовать диагностику сайта, но она видит только публичную сторону и не заменяет доступ к конфигурации сервера.

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

Команды для технической проверки

В примерах замените example.com на свой домен. Набор команд зависит от инфраструктуры: Certbot и systemd могут отсутствовать на панели хостинга, в контейнере или при другом ACME-клиенте.

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -issuer -subject -serial

Команда показывает сертификат, который реально отдаётся при указанном SNI: сроки, издателя, subject и серийный номер. Приватный ключ для этого не используется.

curl -Iv https://example.com

Показывает TLS-рукопожатие, заголовки и редиректы с точки запуска команды. Ошибка на одном сервере ещё не доказывает одинаковый результат во всех сетях.

certbot certificates

systemctl list-timers | grep -i certbot

certbot renew --dry-run

Первые две команды показывают известные Certbot сертификаты и таймер; dry-run проверяет будущую процедуру продления. Не запускайте многократный force-renewal: сначала прочитайте конкретную ошибку и устраните её причину.

nginx -t

Перед любым штатным reload Nginx обязательна успешная проверка конфигурации. Не публикуйте приватный ключ в чатах, тикетах и отчётах. Незнакомые команды нельзя выполнять в production без backup и понимания точки отката; при сомнениях безопаснее заказать аудит безопасности сайта.

Безопасный порядок восстановления HTTPS

1. Зафиксировать текущее состояние: ошибку, время, DNS, активный сертификат и конфигурацию; сделать backup.

1. Определить причину и точку завершения TLS, не смешивая edge и origin.

1. Выпустить или установить сертификат, подходящий доменам, браузерам и географии аудитории.

1. Подключить правильный fullchain и соответствующий приватный ключ с безопасными правами доступа.

1. Проверить конфигурацию штатной командой, например nginx -t.

1. Выполнить предусмотренный инфраструктурой reload без изменения лишних сервисов.

1. Проверить сайт извне и убедиться, что посетитель получает новый сертификат и полную цепочку.

1. Проверить apex, www, IPv4/IPv6, CDN и origin по отдельности.

1. Проверить формы, вход и оплату без реальных отправок и списаний.

1. Проверить HTTPS-редиректы, self-canonical и внутренние ссылки, чтобы они не возвращали посетителя на HTTP.

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

После технического восстановления пройдите пользовательский маршрут от HTTP-адреса до конечного HTTPS URL. Проверьте, что редирект не образует цепочку, canonical указывает на доступную защищённую страницу, а внутренние ссылки, формы и статические ресурсы больше не обращаются к старому протоколу или узлу.

Как предотвратить повторный сбой

Продление должно быть автоматическим, наблюдаемым и регулярно проверяемым. Выполните renew dry-run после первичной настройки и после изменений DNS, CDN, firewall, webroot или Nginx. Контролируйте systemd timer либо cron и храните backup конфигурации отдельно от рабочего сервера.

• настроить внешний мониторинг срока и реального сертификата на edge;

• отправлять предупреждения минимум за 30, 14 и 7 дней до окончания;

• проверять не только apex, но и www, API, поддомены и IPv6;

• документировать, где завершается TLS и кто отвечает за CDN и origin;

• после reload проверять выдаваемый сертификат снаружи, а не только файлы на диске;

• не откладывать автоматизацию: сокращение максимальных сроков делает ручной календарь всё менее надёжным.

Такой контроль полезен и после разового ремонта. Он превращает SSL-сертификат из ручного напоминания в штатный процесс эксплуатации.

FAQ

Можно ли временно вернуть сайт на HTTP?

Для публичного коммерческого сайта обычно нет: HTTP не подтверждает подлинность сервера и не защищает данные в пути. Кроме того, меняются URL, редиректы и canonical. Безопаснее восстановить HTTPS или временно показать статическую страницу на корректно защищённой инфраструктуре.

Безопасен ли бесплатный Let’s Encrypt?

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

Почему сертификат обновлён, но браузер видит старый?

Чаще всего новый файл установлен не в той точке, веб-сервер не перезагружен, запрос попадает на другой узел, либо старый сертификат остаётся на CDN/балансировщике. Сравните SNI, DNS, IPv4/IPv6, edge и origin.

Будет ли российский сертификат работать во всех браузерах?

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

Сколько занимает восстановление?

Фиксированного срока без диагностики нет. Продление на одном Nginx и замена отозванного сертификата в распределённой схеме с CDN, несколькими доменами и мобильным pinning — разные задачи. Сначала нужно установить причину и количество точек установки.

Нужно ли перевыпускать отозванный сертификат?

Да. Отзыв не равен истечению и не отменяется продлением даты. Нужен новый действующий сертификат; при риске компрометации — новая ключевая пара. Старый сертификат удаляют из активной конфигурации после проверенной замены.

SSL-сбой не обязательно мгновенно удаляет страницу из поиска, но мешает пользователям и поисковым роботам получать HTTPS URL, снижает доверие и может влиять на обход, canonical-сигналы и обработку защищённого адреса. После восстановления проверьте доступность, редиректы и индексируемый canonical, а не только значок замка в одном браузере.