Сертификат SSL истёк: что делать в первые двадцать минут
Сайт закрыт предупреждением браузера из-за просроченного сертификата. Как быстро выпустить новый, починить автопродление и не поймать это снова.
Содержание
- Что реально теряется, пока висит предупреждение
- Двадцать минут по шагам
- Диагностика: одна команда вместо десяти кликов
- Выпуск нового: три пути
- Почему автопродление сломалось молча
- Грабли с www и поддоменами
- Проверка после починки
- Как узнавать за две недели, а не от клиента
- Кто за этим следит и сколько стоит
- Частые вопросы
Пока висит красный экран, через него по данным счётчиков проходит от 2 до 6 процентов посетителей, остальные уходят. Первые двадцать минут уходят на диагностику и перевыпуск: панель хостинга делает это за минуту-пятнадцать, консольная утилита за 5-20 минут.
В пятницу вечером у клиента перестали приходить заявки. Сайт при этом работал: отдавал страницы, база живая, хостинг на месте. Просто каждый посетитель сначала упирался в красный экран браузера. Сертификат SSL истёк накануне ночью, автопродление сломалось ещё в мае, и об этом никто не знал, потому что никто не смотрел. Ниже порядок действий на первые двадцать минут, команды для диагностики, три способа выпустить новый сертификат и разбор причин, по которым certbot молча перестаёт работать.
Я веду абонентку шесть лет, и просроченный сертификат стабильно входит в тройку самых обидных аварий. Обидных потому, что чинится за пятнадцать минут, предотвращается бесплатно, а стоит бизнесу как полноценное падение сайта.
Что реально теряется, пока висит предупреждение
Владельцы часто недооценивают масштаб. Кажется, что это косметическая ерунда: ну ругается браузер, ну нажмут «перейти всё равно». Не нажмут.
Chrome показывает полноэкранную заглушку с текстом про недействительный сертификат и кодом NET::ERR_CERT_DATE_INVALID. Кнопка «Дополнительно» спрятана, за ней ещё одна ссылка мелким шрифтом. Firefox выдаёт SEC_ERROR_EXPIRED_CERTIFICATE, Safari на iPhone просто отказывается идти дальше без внятного объяснения. По моим замерам на клиентских Метриках, через такой экран проходит от 2 до 6 процентов посетителей. Остальные закрывают вкладку.
Дальше по цепочке ломается всё, что ходит на сайт программно:
- вебхуки платёжного шлюза перестают доходить, потому что сервер банка проверяет сертификат строго и никакого «перейти всё равно» у него нет;
- обмен с 1С отваливается с ошибкой TLS handshake;
- Яндекс Директ и рекламные кабинеты при плановой перепроверке отправляют объявления на модерацию, а деньги в это время продолжают списываться за клики по объявлениям, ведущим на заглушку;
- Метрика не получает хиты, и в отчётах образуется дыра, из-за которой потом две недели непонятно, что происходило с трафиком;
- почтовые рассылки со ссылками на сайт превращаются в аттракцион с предупреждениями.
Отдельно про поиск. Робот Яндекса при обходе получает ошибку соединения и в Вебмастере появляется рост исключённых страниц. За сутки-двое ничего катастрофического не случится, но неделя такого состояния уже двигает позиции вниз.
И самое неприятное: примерно половина посетителей после красного экрана делает вывод, что сайт взломан. Это другая история, у неё другие причины и другой ремонт, я разбирал её в статье про то, что делать, когда браузер пишет «опасный сайт». Путают их постоянно, потому что оба экрана красные.
Двадцать минут по шагам
Порядок важнее скорости. Я видел, как в панике переустанавливают nginx на боевом сервере, хотя надо было нажать одну кнопку в панели хостинга.
| Минуты | Что делаете | Чем проверяете |
|---|---|---|
| 0-2 | Подтверждаете диагноз, отличаете просрочку от блокировки и заражения | Код ошибки в браузере, инкогнито, мобильный интернет |
| 2-6 | Смотрите даты, издателя и список доменов в сертификате | openssl s_client из консоли или онлайн-чекер |
| 6-8 | Определяете, кто вообще выпускает сертификат на этом проекте | Панель хостинга, наличие certbot, письма от УЦ |
| 8-16 | Выпускаете новый сертификат и перезагружаете веб-сервер | Панель или certbot, затем nginx -s reload |
| 16-20 | Проверяете результат и добиваете хвосты | curl с заголовками, инкогнито, формы, оплата |
Пункт 0-2 пропускать нельзя. Раз в несколько месяцев ко мне приходят с «истёк сертификат», а по факту домен не оплачен, DNS уехал, и браузер ругается совсем на другое.
Диагностика: одна команда вместо десяти кликов
Открывать замочек в адресной строке можно, но браузер кэширует сертификат в рамках сессии и после починки будет какое-то время показывать старый. Смотреть надо с сервера или из терминала.
echo | openssl s_client -connect saitfix.ru:443 -servername saitfix.ru 2>/dev/null
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNameОтвет выглядит так:
subject=CN = saitfix.ru
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=May 18 09:14:03 2026 GMT
notAfter=Aug 16 09:14:02 2026 GMT
X509v3 Subject Alternative Name:
DNS:saitfix.ru, DNS:www.saitfix.ruЧетыре строки, четыре ответа. notAfter в прошлом означает просрочку. issuer говорит, кто выпускал: если там Let’s Encrypt, автопродление в принципе существовало и просто сломалось. subjectAltName показывает, на какие домены выписан сертификат, и вот здесь чаще всего вылезает сюрприз с www.
Если под рукой нет консоли, короткий вариант через curl:
curl -svo /dev/null https://saitfix.ru 2>&1 | grep -E "expire date|subject:|issuer:"Онлайн-чекеры типа SSL Labs или проверялки на сайтах регистраторов тоже годятся, но они лезут снаружи и не покажут, что именно лежит на диске сервера. Когда сертификат уже перевыпущен, а браузер всё ещё ругается, разница между «что на диске» и «что отдаётся» становится ключевой.
Типовые расшифровки:
| Код в браузере | Что на самом деле |
|---|---|
ERR_CERT_DATE_INVALID | Срок вышел. Либо сертификат старый, либо часы на сервере уехали |
ERR_CERT_COMMON_NAME_INVALID | Сертификат живой, но выписан на другой домен или только на www |
ERR_CERT_AUTHORITY_INVALID | Самоподписанный сертификат или неполная цепочка без промежуточного |
ERR_SSL_PROTOCOL_ERROR | Сертификат не отдаётся вообще, порт 443 не слушается или конфиг битый |
ERR_TOO_MANY_REDIRECTS | Сертификат ни при чём, петля в редиректах http и https |
Выпуск нового: три пути
Через панель хостинга
Быстрее всего. Timeweb, Beget, REG.RU, Спринтхост, Джино: у всех в разделе домена есть пункт SSL и кнопка выпуска бесплатного сертификата. Хостинг сам поднимает проверку, кладёт файл в .well-known, забирает сертификат и прописывает его в конфиг. Занимает от одной до пятнадцати минут, стоит ноль рублей.
Единственное, что надо сделать руками: убедиться, что в списке доменов галочками отмечены и голый домен, и www. Панели по умолчанию отмечают то, что вы открыли, а не всё сразу.
Если хостинг предлагает «заказать SSL за 1 900 рублей в год» и прячет бесплатный вариант в другом разделе, это не значит, что бесплатного нет. Разбор того, где искать и чем варианты отличаются, есть в статье про бесплатный SSL в 2026 году.
Через certbot на VPS
Если сервер свой, начинать надо не с выпуска, а с вопроса, что там уже настроено:
certbot certificates
certbot renew --dry-runПервая команда покажет все сертификаты, которые certbot считает своими, с датами и списком доменов. Вторая прогонит продление вхолостую и выведет реальную ошибку. Именно --dry-run обычно и отвечает на вопрос «почему оно само не обновилось»: в выводе будет либо 404 на challenge-файле, либо таймаут, либо отлуп по rate limit.
Когда причина понятна и устранена:
certbot renew --force-renewal
systemctl reload nginxЕсли сертификата в списке нет вообще (сервер переставляли, панель сносили, конфиг переписывали), выпускаем с нуля через webroot, не останавливая веб-сервер:
certbot certonly --webroot
-w /var/www/saitfix.ru/public_html
-d saitfix.ru -d www.saitfix.ru
--agree-tos -m admin@saitfix.ru --non-interactiveПуть в -w должен быть тем самым каталогом, куда смотрит сайт. Ошибка на этом месте даёт 404 при проверке и невнятную жалобу certbot на недоступность challenge.
Платный сертификат
Нужен в трёх ситуациях: хостинг не умеет Let’s Encrypt и не даёт консоль; требуется wildcard на пачку поддоменов без возни с DNS-валидацией; заказчик по внутренним правилам требует OV или EV с проверкой юрлица.
Ориентиры по деньгам на 2026 год: DV-сертификат от 800 до 2 500 рублей в год, wildcard от 4 000 до 9 000, OV от 6 000. Выпуск DV занимает от десяти минут до часа, OV с проверкой документов до трёх рабочих дней. То есть на аварии платный сертификат вас не спасёт, если только у вас нет купленного заранее.
| Способ | Время до рабочего сайта | Деньги | Когда выбирать |
|---|---|---|---|
| Панель хостинга | 1-15 минут | 0 | Shared-хостинг, обычный сайт услуг |
| certbot на сервере | 5-20 минут | 0 | VPS, есть root, нужен контроль |
| Платный DV | 10-60 минут | 800-2 500 в год | Хостинг без поддержки Let’s Encrypt |
| Платный wildcard | 20-90 минут | от 4 000 в год | Много поддоменов, нет доступа к DNS API |
Почему автопродление сломалось молча
Самая частая жалоба звучит так: «у нас же стоял автовыпуск, он год работал». Он и правда работал. Потом что-то изменилось, и попытки продления начали падать, а сообщать о падении было некому.
Отдельно отмечу: Let’s Encrypt с июня 2025 года перестал рассылать письма об истечении срока. Раньше за 20, 10 и 1 день до конца приходило письмо, и это была народная система мониторинга. Теперь её нет. Если вы привыкли, что «нас предупредят», то не предупредят.
Шесть причин, которые я вижу в работе чаще остальных.
Закрыт путь к проверке. Правило в .htaccess или в конфиге nginx редиректит вообще всё на главную или на https, включая /.well-known/acme-challenge/. Удостоверяющий центр стучится за файлом и получает 301 или 403. Проверяется за полминуты:
mkdir -p /var/www/saitfix.ru/public_html/.well-known/acme-challenge
echo ok > /var/www/saitfix.ru/public_html/.well-known/acme-challenge/test.txt
curl -sI http://saitfix.ru/.well-known/acme-challenge/test.txt | head -1Ждём HTTP/1.1 200 OK. Всё остальное означает, что путь перекрыт. Лечится исключением, которое стоит выше редиректов:
RewriteEngine On
RewriteRule ^.well-known/acme-challenge/ - [L]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]Порядок правил здесь решает всё: первое совпадение прекращает обработку.
Сайт переехал, а certbot остался. Классика после смены хостинга. A-запись домена смотрит на новый сервер, проверка уходит туда, а cron с certbot продолжает крутиться на старом и получать 404. Симптом: в логах старого сервера бодрые сообщения о попытках, на новом никаких сертификатов. Порядок нормального переезда со всеми хвостами я расписывал в материале про перенос сайта на новый хостинг.
Задание в кроне исчезло. Systemd-таймер certbot.timer выключен, или crontab пользователя затёрли при переустановке панели. Проверка:
systemctl list-timers | grep certbot
crontab -l | grep -i certbotБот удостоверяющего центра забанен. Плагин безопасности, фаервол хостинга или правило в htaccess режет запросы по user-agent либо по географии. Let’s Encrypt валидирует с нескольких точек мира, и достаточно, чтобы одна из них не прошла. В access-логе такие попытки видно по строкам с acme-challenge и кодом 403.
Упёрлись в лимиты. У Let’s Encrypt пять неудачных валидаций в час на домен и пятьдесят сертификатов на зарегистрированный домен в неделю. Если админ в панике перевыпускал в цикле, следующая попытка получит отлуп на несколько часов. Тут помогает только пауза, поэтому паниковать невыгодно.
Сертификат выпустился, но не подключился. Файлы на диске свежие, а nginx или apache держит в памяти старые и не был перезагружен. Даты в браузере при этом старые, и человек ходит по кругу, перевыпуская снова. Проверять надо тем же openssl s_client, он показывает то, что реально отдаётся в порт.
Грабли с www и поддоменами
Отдельный сюжет, который стоит нервов больше всех остальных вместе взятых.
Сертификат выписан на saitfix.ru, а посетитель заходит на www.saitfix.ru. Домен в сертификате не совпадает, браузер выдаёт ERR_CERT_COMMON_NAME_INVALID, и владелец искренне не понимает, почему «у меня открывается, а у клиента нет». Разница только в трёх буквах, которые кто-то один набирает по привычке.
Что с этим делать:
- выпускать сертификат сразу на оба имени,
-d saitfix.ru -d www.saitfix.ru, это одна строка и ноль дополнительных денег; - держать один канонический вариант и редиректить второй, но редирект тоже отдаётся по https, поэтому сертификат на нём всё равно нужен;
- поддомены вроде
shop.,lk.,staging.считать отдельными сайтами и не забывать про них при выпуске.
Тестовая копия на поддомене с протухшим сертификатом кажется мелочью, ровно до момента, когда на неё приходит робот поисковика или клиент, которому вы полгода назад скинули ссылку на согласование.
Проверка после починки
Замок в адресной строке появился, и на этом обычно все расходятся. Зря: половина хвостов вылезает через день.
Что я прогоняю каждый раз:
- Главная и любая внутренняя страница в режиме инкогнито, с телефона по мобильному интернету. Обычная вкладка врёт из-за кэша.
- Редиректы без петли:
curl -sIL http://saitfix.ru | grep -E "^HTTP|^[Ll]ocation"Должно быть максимум два перехода и финальный 200. Три и больше означают, что правила спорят между собой.
- Полнота цепочки. Браузер на десктопе часто подтягивает промежуточный сертификат сам и молчит, а старый Android и внешние сервисы валятся с ошибкой доверия.
openssl s_clientбез-showcertsпокажетVerify return code: 0 (ok), если всё в порядке. - Смешанный контент: после перевыпуска иногда всплывают старые ссылки на картинки по http, замок становится серым с предупреждением.
- Формы. Отправить тестовую заявку и убедиться, что она дошла в почту и в мессенджер. Обработчик формы ходит по https сам к себе чаще, чем кажется.
- Оплата и внешние интеграции: тестовый платёж, обмен с 1С, вебхуки. Именно они молчат дольше всего.
- Счётчик Метрики: проверить, что хиты снова идут, и отметить период аварии, чтобы через месяц не искать несуществующую проблему с трафиком.
- Вебмастер: отправить главную на переобход, если простой длился больше суток.
Как узнавать за две недели, а не от клиента
Это единственная часть статьи, которая экономит деньги, а не тратит их. Настраивается один раз.
Первый вариант, бесплатный и без сервера. UptimeRobot умеет следить за сроком сертификата и присылать уведомление за 14, 7 и 1 день. Pinger и подобные российские сервисы делают то же самое от 350 рублей в месяц, зато с оповещением в Telegram и без проблем с оплатой зарубежной картой. Общая логика мониторинга доступности разобрана в статье про мониторинг сайта, там же про то, куда должны падать алерты, чтобы их кто-то прочитал.
Второй вариант, свой скрипт на любом сервере с доступом в интернет. Кладём в /usr/local/bin/ssl-check.sh:
#!/bin/sh
DOMAIN="saitfix.ru"
TOKEN="123456:AA..."
CHAT="12345678"
END=$(echo | openssl s_client -connect "$DOMAIN":443 -servername "$DOMAIN" 2>/dev/null
| openssl x509 -noout -enddate | cut -d= -f2)
LEFT=$(( ( $(date -d "$END" +%s) - $(date +%s) ) / 86400 ))
if [ "$LEFT" -lt 14 ]; then
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage"
-d chat_id="$CHAT"
-d text="$DOMAIN: сертификат истекает через $LEFT дн."
fiИ в crontab одну строку:
0 9 * * * /usr/local/bin/ssl-check.shВажная деталь: скрипт должен жить не на том же сервере, что и сайт. Когда сервер ляжет целиком, вместе с ним ляжет и сторож. Я держу такие проверки на отдельной машине, которая обслуживает всех клиентов сразу.
Третье, про что стоит знать заранее. Максимальный срок жизни публичных сертификатов сокращается: с марта 2026 года потолок 200 дней, дальше по графику CA/Browser Forum он будет уменьшаться и к 2029 году дойдёт до полутора месяцев. Ручное продление раз в год ещё как-то жило. Ручное продление раз в семь недель не выживет ни у кого. Если автопродление до сих пор не настроено, это вопрос ближайшего года, а не отдалённого будущего.
Кто за этим следит и сколько стоит
Честный ответ: следить должен тот, у кого есть доступ к серверу и привычка смотреть в мониторинг. У владельца бизнеса такой привычки нет и быть не должно.
В моей абонентке проверка срока сертификатов входит в базу вместе с бэкапами, обновлениями и мониторингом доступности. Годовой тариф 35 000 рублей, помесячный от 15 000, детали на странице тарифов. Разовое восстановление просроченного сертификата с разбором причины и настройкой автопродления я делаю за час-полтора, но платить за аварию всегда дороже, чем за то, чтобы её не было.
Что в такие работы не входит: разработка сайта с нуля и дизайн. Я занимаюсь чужими сайтами, которые уже работают, и слежу, чтобы они продолжали работать.
Если сертификат истёк прямо сейчас и разбираться некогда, напишите через форму и приложите домен с названием хостинга. По этим двум строчкам обычно уже понятно, куда идти и сколько это займёт. Остальные разборы по безопасности собраны в рубрике.
Частые вопросы
Что делать, если истёк SSL-сертификат
Перевыпустить: через панель хостинга или штатной утилитой на сервере. Это минуты. Дальше разобраться, почему сломалось автопродление, иначе история повторится через три месяца.
Почему автопродление сломалось молча
Обычно из-за редиректа, который перехватывает служебный путь проверки, из-за прав на папку или из-за того, что домен переехал. Уведомлений об этом никто не шлёт, поэтому узнают от клиентов.
Сколько стоит сертификат
Ноль, если брать бесплатный. Платный на один домен стоит порядка 800-2500 рублей в год, на все поддомены сразу от 4000. Покупать имеет смысл только второй вариант и только при реальной нужде.
Как узнавать заранее
Поставить мониторинг срока действия сертификата с уведомлением за две недели. Это бесплатно и снимает весь класс проблемы.
