Как обновить SSL-сертификат сайта и не поймать простой

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

Слово «продление» вводит в заблуждение: срок действия внутри выданного файла изменить нельзя. Продление — это всегда выпуск нового сертификата на тот же домен и замена файлов на сервере. Отсюда два практических следствия.

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

Приватный ключ при перевыпуске можно оставить прежним, но безопаснее генерировать новый — certbot по умолчанию так и делает. Если ключ меняется, а сертификат в конфиге прописан по прямому пути к файлу с датой в имени, вы получите рассинхронизацию: сервер будет читать новый сертификат со старым ключом. Именно поэтому в конфигурации всегда указывают путь через каталог live/, который является символической ссылкой на актуальную версию.

Почему тянуть с автоматизацией больше нельзя

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

Направление движения хорошо известно: от 398 дней, привычных ещё недавно, к примерно 200 дням, дальше к сотне дней в 2027 году и к сорока семи в 2029-м. Что это означает практически:

• Регламент «раз в год админ покупает и ставит сертификат» перестаёт существовать как класс.
• Ручная замена превращается в ежеквартальную, а затем и ежемесячную операцию — то есть в гарантированный источник человеческих ошибок.
• Автоматический выпуск по протоколу ACME становится единственным жизнеспособным способом, включая платные сертификаты, — поставщики уже предлагают ACME-доступ.

Вывод для владельца сайта: вопрос «как обновить SSL-сертификат» правильнее переформулировать в «как сделать так, чтобы его больше никогда не приходилось обновлять руками».

Автопродление Let’s Encrypt: как убедиться, что оно живое

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

1. Пробное продление: sudo certbot renew --dry-run. Команда проходит весь цикл, кроме фактической записи, и покажет реальную ошибку валидации, если она есть.
2. Планировщик на месте: systemctl list-timers | grep certbot либо запись в cron. После переезда на другой сервер таймер часто теряется.
3. Хук перезагрузки настроен: в конфигурации должен быть --deploy-hook "systemctl reload nginx" или аналог. Без него файлы обновятся, а посетители продолжат получать старый сертификат до ближайшего рестарта сервера.
4. Порт 80 открыт и запросы к /.well-known/acme-challenge/ не перехватываются редиректами и антибот-правилами. Это причина номер один у неудачных автопродлений.

И ещё одна деталь, о которой многие не знают: Let’s Encrypt прекратил рассылать письма-напоминания об истечении срока. Рассчитывать на входящее письмо как на систему оповещения больше нельзя — нужен собственный мониторинг.

Обновление платного сертификата без простоя

Порядок действий, который мы применяем на клиентских проектах:

1. За 2-3 недели до истечения оформить перевыпуск. Для DV хватит часа, для OV — до трёх рабочих дней, для EV — до десяти: проверка компании ведётся людьми и может встать на праздниках.
2. Сгенерировать новый CSR на сервере. Приватный ключ не покидает сервер — если поставщик предлагает создать ключ на своей стороне, это повод сменить поставщика.
3. Пройти валидацию — файлом на сайте, TXT-записью или письмом на служебный ящик домена. Проверьте заранее, что ящик вида admin@ рабочий: с ним связана львиная доля срывов.
4. Положить новые файлы рядом со старыми, не удаляя предыдущие. Собрать полную цепочку: ваш сертификат, затем промежуточные из бандла.
5. Переключить пути в конфиге, проверить синтаксис и перезагрузить: sudo nginx -t && sudo systemctl reload nginx. Reload не рвёт активные соединения — сайт не моргнёт.
6. Проверить снаружи: echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -dates и открыть сайт с телефона.

Старые файлы удаляйте через несколько дней, когда убедились, что всё стабильно. Возможность откатиться одной строкой в конфиге стоит дешевле любой ночной эвакуации.

Шесть причин, по которым сайт всё-таки падает

• Не перезагрузили веб-сервер. Файлы новые, память старая. Самая частая причина падения «через 90 дней после успешной настройки».
• Сертификат используется несколькими сервисами. Nginx перечитал, а почтовый сервер, панель управления или приложение в контейнере — нет. Каждый потребитель сертификата должен быть в хуке обновления.
• Изменился набор доменов. Добавили поддомен в сайт, но не в сертификат — посетители поддомена получают ошибку несовпадения имени.
• Заблокирована проверка домена. Включили Cloudflare в режиме проксирования, поставили защиту от ботов или закрыли порт 80 — HTTP-проверка перестала проходить, а узнали об этом через три месяца.
• Домен переехал на другой сервер, а certbot остался на старом и продолжает обновлять сертификат в пустоту.
• Закончилась оплата домена. Домен снят с делегирования — валидация невозможна в принципе, и сертификат не продлевается по причине, которая к серверу отношения не имеет.

Все шесть сценариев объединяет одно: они происходят молча. Сбой автопродления не создаёт ошибки на сайте сегодня — он создаёт её через несколько недель, когда причину уже никто не помнит.

Мониторинг: узнать раньше, чем клиент

Минимальный рабочий вариант — задание в cron, которое раз в сутки смотрит дату окончания и пишет вам, когда остаётся меньше 14 дней. Дата вытаскивается одной командой: echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -enddate. Проверять нужно именно через внешнее подключение к сайту, а не файл на диске: файл может быть свежим, а отдаваться будет старый.

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