SSL-сертификат истёк: что делать и как не пропустить

Сертификат истёк ночью, утром на сайт зашёл первый клиент, увидел красную плашку «ваше подключение не защищено» и закрыл вкладку. К обеду половина дневного трафика — мимо. Знакомая картина? У меня — раз в год точно случается у кого-то из знакомых, кто решил «попозже разберусь с автопродлением».

Эта статья — что делать, если SSL-сертификат истёк прямо сейчас, и как один раз настроить, чтобы больше не возвращаться к этому вопросу.

TL;DR — пять шагов на горящем сайте

1. Подтвердить, что упал именно SSL, а не что-то ещё (одной командой, ниже).
2. Если стоит Let's Encrypt — certbot renew --force-renewal и рестарт веб-сервера.
3. Если сертификат от платного CA — выпустить новый там же, где брали, положить файлы на сервер.
4. Проверить, что в браузере зелёный замок, в curl -vI — ответ 200.
5. Поставить мониторинг сертификата с алёртом за 30/7/1 день, чтобы это была последняя такая ночь.

Дальше — детали по каждому шагу, разбор причин и FAQ. Не торопитесь — на пункт 2 уйдёт минут десять, не больше.

Как понять, что упал именно сертификат

В браузере подсказка прямая: NET::ERR_CERT_DATE_INVALID в Chrome, «Срок действия сертификата истёк» в Firefox, в Safari похожее. Но я никогда не доверяю одному браузеру — кешированный OCSP, корпоративный MITM, локальное время сбилось. Лучше дёрнуть с сервера или из терминала.

Однострочник, который я держу в шпаргалке:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

Ответ должен выглядеть так:

notBefore=Mar  1 00:00:00 2026 GMT
notAfter=May 30 23:59:59 2026 GMT

notAfter уже в прошлом — да, сертификат истёк, и браузеры правы. Если в notAfter будущее, но сайт всё равно ругается — проблема не в сроке, а где-то ещё (промежуточный сертификат, неправильный SNI, имя в сертификате не совпадает с доменом). Это уже другая история.

Дополнительная команда, которая показывает заодно цепочку:

curl -vI https://example.com 2>&1 | grep -E "expire|subject|issuer"

Если curl сам по себе ругается на сертификат — это уже почти диагноз. Дальше — лечение.

Срочный фикс: четыре сценария

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

Сценарий 1: Let's Encrypt + certbot (самый частый)

Это пара строк:

sudo certbot renew --force-renewal
sudo systemctl reload nginx   # или apache2, или ваш веб-сервер

--force-renewal нужен, потому что обычный renew ничего не делает, если до истечения больше 30 дней (он сам отказывается лишний раз дёргать ACME). Если сертификат уже мёртв — флаг говорит «не спрашивай, обнови».

Что может пойти не так на этом шаге:

• Rate limit Let's Encrypt. Если вы уже несколько раз пытались — упрётесь в лимит 5 выпусков на домен в неделю. Лечится либо ожиданием, либо переходом на --dry-run для отладки и реальным выпуском один раз.
• DNS-01 challenge упал. Часто у тех, у кого DNS на одном провайдере, а сертификат выпускается через wildcard. Проверьте, что TXT-запись _acme-challenge создаётся.
• 80 порт закрыт. HTTP-01 ходит по 80-му, и если вы его прибили в фаерволе после первой настройки — продление сломается тихо. Откройте на время продления.

Сценарий 2: Caddy (про него часто забывают)

Caddy сам ходит за сертификатами и сам их продлевает. Если он перестал — обычно дело либо в правах на /var/lib/caddy, либо в том, что инстанс не доходит до ACME. Команда:

sudo systemctl restart caddy
sudo journalctl -u caddy -n 100 --no-pager

В логах будут понятные сообщения — Caddy в этом плане многословный.

Сценарий 3: Сертификат от платного CA (GlobalSign, Sectigo, DigiCert, RU CA)

Здесь руками: идёте в личный кабинет CA, нажимаете «перевыпустить», получаете три файла — сам сертификат, промежуточный (intermediate) и приватный ключ (если новый CSR). Кладёте на сервер, перезагружаете веб-сервер.

В nginx это обычно /etc/nginx/ssl/:

sudo cp example.com.crt /etc/nginx/ssl/
sudo cp example.com.key /etc/nginx/ssl/
sudo nginx -t && sudo systemctl reload nginx

Самая частая ошибка — забыть склеить fullchain. Если сертификат и intermediate отдельными файлами, многие клиенты (особенно мобильные и старые Java-стэки) посчитают цепочку битой. Делается так:

cat example.com.crt intermediate.crt > /etc/nginx/ssl/example.com.fullchain.crt

И в конфиге nginx — путь именно к fullchain, не к голому сертификату.

Сценарий 4: SSL на хостинге через панель (Plesk, ISPmanager, cPanel)

Тут обычно есть кнопка «обновить» прямо в панели. У большинства хостеров это работает в один клик, если домен прописан корректно и DNS не сбит. Если кнопка ничего не делает — пишите в поддержку хостинга, скорее всего у них автопродление само по себе сломалось у пачки клиентов.

Почему вообще истекло — четыре частые причины

Каждый раз, когда такое случается, оказывается одно из:

Из моего опыта — половина случаев это первый пункт. Кто-то заменил systemd, кто-то выключил таймер «чтобы не нагружать», кто-то перенёс сервер и забыл включить заново. Таймер тихо лежит, certbot не запускается, сертификат тикает к 0.

Профилактика: мониторинг с предупреждением заранее

Чинить упавший сертификат в три ночи — неприятно. Получить уведомление за 30 дней до истечения, спокойно продлить днём — приятно. Разница в одной настройке.

Самое простое — поставить мониторинг SSL-сертификата с алёртом по нескольким порогам сразу. Я обычно делаю три ступени:

• 30 дней — информационно, чтобы знать, что время идёт.
• 7 дней — предупреждение в рабочий чат, ставится таска.
• 1 день — критический алёрт в Telegram, телефон жужжит ночью.

В PingMap это делается через мониторинг SSL-сертификата — добавляете домен, выбираете пороги, привязываете канал доставки. Алёрт можно завернуть в Telegram-бот, и тогда вы реально не пропустите, даже если на проекте давно никто не смотрит в почту.

Pro tip: проверяйте не только основной домен, но и все поддомены, которые используются. У меня был случай: основной домен в порядке, а api.example.com сидит на отдельном сертификате, и про него все забыли. Лёг в первую очередь, потому что именно его дёргал мобильный клиент.

Если работаете с командой — заодно поставьте публичную статус-страницу. Когда сертификат всё-таки упадёт (а оно когда-нибудь случится), у пользователей хотя бы будет место посмотреть, что происходит, и не разводить панику в саппорте.

Проверка после восстановления

После любого из четырёх сценариев — три быстрые проверки:

# 1. Сертификат живой и срок свежий
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

# 2. Цепочка собрана правильно (нет "verify error")
curl -vI https://example.com 2>&1 | grep -E "verify|expire|HTTP"

# 3. Полная оценка от SSL Labs (если есть пара минут)
# https://www.ssllabs.com/ssltest/analyze.html?d=example.com

Если все три зелёные — можно выдохнуть. Параллельно стоит зайти в браузере с очищенным кешем и с мобильного устройства — иногда промежуточный сертификат криво подцепляется, и десктоп показывает зелёный замок, а Android ругается. Это всё та же история с fullchain.

Если что-то всё ещё не складывается — обычно помогает разобраться по той же логике, что в статье «Почему сайт не работает»: разделить слои и проверить каждый по отдельности. И TCP-соединение проверить заодно — бывает, что проблема не в самом сертификате, а в том, что 443 порт где-то перекрыт.

FAQ

Можно ли продлить уже просроченный SSL-сертификат?

Технически — нет, продлевают только действующие. Если истёк, надо выпустить новый сертификат для того же домена. Для Let's Encrypt и большинства CA это бесплатно или входит в подписку, и занимает столько же времени, сколько обычное продление. Просто не путайте термины: внутри certbot и cron-задач это всё называется renew, но фактически это новый выпуск.

Потеряются ли SEO-позиции, если сайт несколько часов лежал с просроченным SSL?

В большинстве случаев — нет, если успели починить в течение суток. Гугл не выкидывает страницы за единичный инцидент с сертификатом, но фиксирует доступность в Search Console и может временно понизить, если падение длится больше суток-двух. Гораздо болезненнее — потеря пользователей: они видят красную плашку, закрывают вкладку и часть из них не возвращается.

Что делать с HSTS, если сайт лежит?

Если у вас включён HSTS (особенно с preload) — браузер откажется грузить сайт даже после фикса, пока не истечёт max-age в кеше. Это сделано специально и обойти нельзя. Поэтому HSTS с большим max-age (год, два года) стоит включать только когда автопродление надёжно работает уже несколько циклов подряд. Если включаете впервые — начните с max-age=300 на пару недель, потом постепенно поднимайте.

Сколько по факту даёт Let's Encrypt и почему?

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

Можно ли поставить wildcard и забыть?

Wildcard покрывает все поддомены одного уровня (*.example.com — это api.example.com, www.example.com, но не staging.api.example.com). Удобно, но имеет нюансы: wildcard от Let's Encrypt требует DNS-01 challenge, что сложнее настроить. И, главное, единая точка отказа — упал wildcard, упало всё. Я предпочитаю отдельные сертификаты на каждый поддомен — больше шумных рутинных продлений, но меньше радиус взрыва.

Что делать, если сертификат от российского CA, который попал под санкции?

Перевыпуск — у действующего российского CA (РТК, IT.RU, есть несколько). Или переход на Let's Encrypt, если он у вас работает (Let's Encrypt в РФ работает, ACME ходит на их инфраструктуру). Третий вариант — Минцифры выдаёт государственные сертификаты бесплатно через Госуслуги, но их распознают не все браузеры (Chrome — да, после установки корневого; Firefox — частично; Safari — нет). Выбор зависит от того, кто ваши клиенты.

В сухом остатке

Истёкший сертификат — не катастрофа, если поймать в первые часы. Через 10 минут после команды certbot renew --force-renewal сайт обычно снова отдаёт зелёный замок. Хуже — если узнать об этом не от мониторинга, а от клиента в саппорте. Поэтому реальная защита тут не в скорости фикса, а в том, чтобы такой ночи больше не было.

Поставьте мониторинг SSL-сертификата с алёртом за 30 дней до истечения — у PingMap бесплатно, и настраивается за пару минут. Один раз сделать — потом просто продлеваете спокойно днём, без аврала.