SSL-сертификат не обновился

MAATRIX

Браузер вдруг показывает «Подключение не защищено», а в углу — перечёркнутый замок. Чаще всего причина одна: SSL-сертификат не обновился вовремя и истёк. Для Let's Encrypt, который живёт всего 90 дней и должен продлеваться автоматически, это типичный сбой. Ниже пошаговое решение проблемы — как обновить сертификат прямо сейчас, найти причину, по которой автопродление молча сломалось, и настроить его так, чтобы больше не повторялось.

Быстрое решение: обновить сертификат вручную

Первым делом верните сайту рабочий сертификат. Если вы используете certbot (стандартный клиент Let's Encrypt), обновление запускается одной командой. Сначала проверим текущее состояние, затем принудительно обновим:

# что с сертификатами и когда истекают
certbot certificates
# попытка обновить всё, что близко к истечению
certbot renew
# если сертификат уже истёк — принудительное обновление
certbot renew --force-renewal
# перезагрузить веб-сервер, чтобы подхватил новый сертификат
systemctl reload nginx

Ключевой момент, который часто забывают: после обновления сертификата веб-сервер нужно перезагрузить, иначе он продолжит отдавать старый из памяти. Если certbot renew отработал без ошибок и nginx reload прошёл — обновите страницу, замок должен вернуться. Если же команда выдала ошибку, переходим к диагностике причины: именно она мешала и автоматическому продлению.

Проверяем срок и издателя сертификата

Чтобы понимать, с чем имеете дело, посмотрите на сертификат со стороны — как его видит браузер. Это отсекает путаницу «обновил, а всё равно старый»:

# срок действия сертификата, который реально отдаёт сайт
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer

Строка notAfter покажет дату истечения. Если она в прошлом — сайт действительно отдаёт просроченный сертификат, и, скорее всего, автопродление не работало давно. Если дата свежая, но браузер ругается — проблема не в сроке, а, например, в неполной цепочке сертификатов или в том, что сервер отдаёт сертификат не для того домена. Поле issuer подтверждает, что сертификат от Let's Encrypt, а не самоподписанный, случайно попавший в конфиг.

Почему автопродление молча ломается

Самое обидное в этой проблеме — она копится тихо. Автопродление «отвалилось» три месяца назад, но вы узнаёте об этом в день истечения по ошибке в браузере. Разберём главные причины. Первая и самая частая — сломанный HTTP-челлендж. Let's Encrypt для продления обращается к вашему сайту по адресу /.well-known/acme-challenge/, и если этот путь недоступен (изменился конфиг, добавился редирект всего на HTTPS, закрылся 80-й порт), проверка проваливается.

# смотрим, что пошло не так при последнем продлении
certbot renew --dry-run
# логи certbot
tail -50 /var/log/letsencrypt/letsencrypt.log

Команда --dry-run прогоняет продление в тестовом режиме без расхода лимитов и честно показывает, где спотыкается. Вторая частая причина — не запущен таймер автопродления: пакет certbot обычно ставит systemd-таймер или cron-задание, но при ручной установке или после переноса сервера оно могло не создаться. Третья — блокировка 80-го порта фаерволом, из-за которой челлендж не проходит.

Отдельно стоит сказать про коварство именно этого класса сбоев: они не подают признаков жизни до самого дня истечения. Веб-сервер продолжает отдавать ещё действующий сертификат, сайт работает, ничто не намекает на проблему — а фоновое продление уже три месяца тихо падает при каждой попытке. Поэтому одной починки мало, нужна ранняя сигнализация. Настройте отправку писем об истечении (Let's Encrypt шлёт их на указанную при выпуске почту) и хотя бы раз в месяц заглядывайте в certbot certificates. Привычка проверять состояние заранее превращает потенциальную аварию в спокойную плановую операцию, которую вы делаете задолго до того, как о ней узнают посетители.

Чиним автопродление

Когда причина ясна, чиним по адресу. Если не работал таймер — проверяем и включаем его:

# есть ли таймер и когда сработает
systemctl list-timers | grep certbot
# включить, если выключен
systemctl enable --now certbot.timer

Если ломался HTTP-челлендж из-за редиректа на HTTPS — убедитесь, что путь /.well-known/acme-challenge/ отдаётся по HTTP без перенаправления. В конфиге Nginx это отдельный location выше общего редиректа. Если мешает фаервол — откройте 80-й порт хотя бы для проверки: ufw allow 80/tcp. Для сайтов за проксирующим CDN иногда надёжнее перейти на DNS-челлендж, который не требует доступа к сайту по HTTP вовсе. После починки обязательно прогоните certbot renew --dry-run — успешный тест означает, что теперь продление пройдёт само.

Другие причины ошибки с сертификатом

Не всякая ошибка замка — это истечение. Разберём соседние случаи, чтобы не чинить не то. Неполная цепочка: сервер отдаёт только сам сертификат без промежуточного, и часть клиентов (особенно старые и мобильные) ему не доверяют. Лечится указанием полной цепочки (fullchain.pem, а не cert.pem) в конфиге. Несовпадение домена: сертификат выпущен на example.com, а сайт открыли как www.example.com, которого в сертификате нет.

Ещё вариант — сертификат обновился, но веб-сервер не перезагрузили, и он держит старый в памяти; помогает systemctl reload. И банальное: неверный системный час на сервере может ломать проверку срока действия. Каждая из этих причин даёт «ошибку безопасности», но лечится по-разному, поэтому сначала стоит точно определить, в сроке дело или в конфигурации.

Профилактика: чтобы сертификат не истекал

Правильно настроенное автопродление снимает проблему полностью. Убедитесь, что таймер certbot включён и реально срабатывает, — он пытается обновлять сертификаты дважды в день и продлевает их за 30 дней до истечения, с большим запасом. Раз в пару месяцев не поленитесь глянуть certbot certificates — минутная проверка избавляет от аварии.

• Держите включённым certbot.timer (или cron-задание).
• Не редиректьте /.well-known/acme-challenge/ на HTTPS.
• Не закрывайте 80-й порт наглухо, если используете HTTP-челлендж.
• Настройте уведомления об истечении на почту.
• В конфиге указывайте fullchain.pem, чтобы цепочка была полной.

Стабильная работа автопродления начинается с нормального сервера, где вы контролируете конфиг, порты и планировщик. У MAATRIX VPS в локациях RU, US и UK дают полный root-доступ, оплата из России картой или криптой — вы настраиваете certbot один раз, и сертификаты обновляются сами, а вы вспоминаете о них разве что при большой перестройке сайта.

Частые вопросы