Let’s Encrypt сокращает срок сертификатов: готовим продление к 2027 году

MAATRIX · 17 октября 2026 · 8 мин чтения

В календаре администратора живёт напоминание: «через два месяца обновить сертификат». Пока сертификат действует девяносто дней, такая схема иногда даже выглядит надёжной. Но календарь не знает, что срок выпуска изменился, сотрудник заболел, а Nginx после обновления файлов продолжает отдавать старый сертификат.

Let’s Encrypt постепенно сокращает сроки. Это не повод срочно перевыпускать всё вручную. Это повод проверить, умеет ли существующая автоматизация работать с реальным сроком сертификата, а не с привычкой человека помнить число девяносто.

Что меняется и когда

На 17 октября 2026 года нельзя говорить, что все сертификаты Let’s Encrypt уже стали сорокапятидневными. У центра сертификации есть разные профили, а изменение стандартного профиля идёт поэтапно.

Согласно опубликованному плану, для стандартного classic переход к сроку 64 дня назначен на 10 февраля 2027 года. Следующий шаг, до 45 дней, запланирован на 16 февраля 2028 года. Изменение касается новых выпусков после соответствующей даты, включая очередное продление.

Профиль tlsserver уже предлагает 45-дневные сертификаты для тех, кто выбрал его явно. Отдельный shortlived используется для значительно более короткого срока, в том числе сертификатов на IP. Сопоставление возможностей находится в описании профилей.

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

Автоматическое продление — это целая цепочка

Для рабочего HTTPS недостаточно получить новый сертификат. Клиент должен вовремя запуститься, пройти проверку контроля адреса, записать файлы, передать их нужной службе и добиться загрузки. После этого внешний пользователь должен увидеть именно новый сертификат.

Каждый участок способен сломаться независимо. Таймер работает, но DNS-токен отозван. Выпуск успешен, но файлы записаны в другой каталог. Nginx перечитал конфигурацию, но перед ним стоит балансировщик со своей копией. Журнал сообщает «успех», а посетитель получает вчерашнюю проблему.

Поэтому начните с карты маршрута. Запишите все места завершения TLS: CDN, балансировщик, обратный прокси, само приложение, почтовый сервер. У каждого могут быть отдельный сертификат и отдельный способ обновления.

Не ограничивайтесь главным доменом. Служебные поддомены, вебхуки, панель мониторинга и почта обычно вспоминаются последними. Именно они иногда удерживают весь рабочий процесс, пока основной сайт продолжает радостно открываться.

Инвентаризация без перевыпуска

На сервере с Certbot сначала посмотрите управляемые линии сертификатов:

sudo certbot certificates

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

Найдите механизм запуска renew. В зависимости от установки это может быть systemd timer, cron или задача внутри панели. Проверяйте конкретный механизм, а не наличие слова certbot в списке пакетов. Два независимых планировщика также нежелательны: они осложняют понимание результата.

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

Отдельно отметьте ручные операции. Если сотрудник должен скопировать TXT-запись, подтвердить запрос или загрузить файл через панель, процесс ещё не полностью автоматизирован. Короткий срок просто делает эту зависимость заметнее.

Обновите клиент прежде, чем менять расписание

Современный ACME-клиент умеет учитывать срок и возможности центра сертификации. Сначала проверьте его версию, источник установки и поддержку нужных функций. Древний клиент с новой строкой cron не становится современным.

Let’s Encrypt рекомендует механизм ARI — ACME Renewal Information, который позволяет сообщать клиенту рекомендуемое окно продления. Включение и фактическая поддержка зависят от клиента; ориентируйтесь на его документацию и описание ARI.

Не закладывайте в собственный скрипт вечные девяносто дней. Если клиент не поддерживает ARI, он должен принимать решение по фактическому периоду действия и регулярно иметь возможность выполнить продление. Сам запуск проверки может происходить часто, а новый сертификат запрашивается только при необходимости.

Не используйте принудительный перевыпуск каждый день как замену правильной логике. Это создаёт лишние запросы и мешает понимать аварии. Ограничения и особенности продлений опубликованы в правилах rate limits. Для отладки предназначена тестовая среда, а не серия случайных запросов к production.

Проверьте способ подтверждения контроля

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

При DNS-01 проверьте срок и права API-токена, выбранную зону и способ распространения записи. Токену нужны необходимые возможности, но не безусловный доступ ко всем доменам организации. Не храните его в общедоступном репозитории вместе с инструкцией продления.

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

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

Репетиция должна включать доставку сертификата

Для Certbot выполните пробное продление конкретной линии. Имя site-prod ниже — пример, используйте имя из своего списка:

sudo certbot renew --cert-name site-prod --dry-run

Поведение пробного режима и hooks описано в руководстве Certbot. Успех проверки подтверждает возможность пройти выпуск, но не обязательно доказывает, что все действия после него были выполнены. Deploy hooks по умолчанию требуют отдельного внимания при dry run.

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

Внешняя проверка должна смотреть на реальный адрес сервиса. Убедитесь, что показывается нужный серийный номер и срок, а цепочка доверия принимается клиентом. Для балансировщика с несколькими узлами важно проверить каждый путь, а не только тот, который случайно выбрал один запрос.

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

Предупреждение должно приходить раньше беды

Мониторинг срока сертификата лучше выполнять независимо от машины, которая его выпускает. Если VPS недоступен, локальный скрипт не сможет сообщить о собственной проблеме. Внешний наблюдатель проверит и доступность, и фактически предъявленный сертификат.

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

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

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

Где разместить проверку и как оценить ресурсы

Для небольшого внешнего мониторинга можно выделить отдельный VPS MAATRIX Ba Lite с 1 vCPU и 2 GB памяти. Если рядом собираются метрики и журналы нескольких систем, ресурсы рассчитывают по выбранному инструменту и сроку хранения. Само продление обычно не является главным потребителем памяти сервера.

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

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

Что должно быть готово к февралю

К переходу стандартного профиля на 64 дня у каждого сервиса должны быть понятный владелец, актуальный клиент, работающая проверка контроля и проверенная загрузка нового сертификата. Расписание не должно зависеть от неизменного срока в девяносто дней.

Необязательно специально менять профиль всех рабочих сайтов ради подготовки. Можно испытать более короткий срок на отдельном стенде и проверить цепочку целиком. Главное — измеримый результат, а не галочка «автопродление включено» в панели.

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