Let’s Encrypt сократит срок сертификатов до 64 дней: что проверить на сайте

Let’s Encrypt объявила о сокращении стандартного срока действия TLS-сертификатов с 90 до 64 дней. Анонс опубликован 7 октября 2026 года; для рабочих сайтов переход запланирован на 10 февраля 2027-го. Владельцам сайтов стоит использовать оставшееся время, чтобы проверить автопродление HTTPS: ручное обслуживание сертификатов становится ещё менее удобным.

TLS-сертификат используется для защищённого соединения с сайтом. Обычно его выпуском и заменой занимается хостинг, панель управления или специальная программа. Поэтому главный вопрос для владельца проекта — кто отвечает за этот процесс и как он узнаёт о сбое.

Когда начнётся переход

Изменение вводится поэтапно. Оно касается сертификатов, которые Let’s Encrypt выпустит или продлит после переключения стандартного срока. Уже выданные действующие сертификаты из-за этого перехода отзывать не будут.

• 14 октября 2026 года: 64-дневные сертификаты появятся в staging — тестовой среде Let’s Encrypt.
• 10 февраля 2027 года: новый срок станет стандартным в рабочей среде.
• 11 мая 2027 года: ожидается истечение срока последнего 90-дневного сертификата.

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

Что меняется для автоматического продления

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

Протокол ACME — автоматизированное управление сертификатами — позволяет программе общаться с удостоверяющим центром. Расширение ARI, то есть ACME Renewal Information, передаёт клиенту рекомендованное окно продления. Оно описано в стандарте RFC 9773: сервер сообщает подходящий промежуток времени, а клиент выбирает момент обращения внутри него. Такой подход уменьшает зависимость от фиксированных предположений о сроках.

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

В старых скриптах может быть зашито правило вроде «получать новый сертификат каждые 80 дней». При более коротком сроке такая схема перестаёт оставлять запас. Let’s Encrypt рекомендует для фиксированной логики ориентироваться примерно на прохождение двух третей срока действия. Для 64 дней это около 43 дней после выпуска — расчётный ориентир, а не универсальная настройка для любого клиента.

Не стоит превращать это число в новое редкое расписание cron. Cron — планировщик заданий — должен давать клиенту возможность вовремя проверить состояние и повторить неудачную попытку. А решение о выпуске нового сертификата должен принимать сам клиент с учётом срока и, при наличии поддержки, рекомендаций ARI.

Как проверить сервер с Certbot

Certbot — один из клиентов для получения и продления сертификатов. На сервере, где он уже используется, начать можно с просмотра версии, списка сертификатов и тестового продления:

certbot --version
sudo certbot certificates
sudo certbot renew --dry-run

Это пример для Linux-сервера с установленным Certbot. На обычном хостинге, где сертификатами управляет провайдер, выполнять эти команды негде: там проверку проводят через панель или поддержку.

В стандартной конфигурации Let’s Encrypt параметр --dry-run проверяет продление через тестовую среду без сохранения полученных сертификатов. Если у клиента задан другой ACME-сервер, поведение нужно сверить с его настройками. После 14 октября такой тест позволит проверить процесс уже с новым сроком действия в staging.

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

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

Получить сертификат — ещё не весь процесс

Для администратора полезно рассматривать HTTPS как последовательность действий: подтверждение владения доменом, выпуск сертификата, его доставка к сервису и применение новой версии. Сбой возможен на каждом этапе. Например, новый файл может появиться на сервере, но обслуживающий запросы процесс продолжит использовать прежний сертификат.

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

Второй полезный контроль — смотреть на сертификат, который сайт отдаёт посетителю, а не только на файл в каталоге. Если перед приложением стоит прокси, балансировщик или CDN, точка завершения TLS может находиться там. Для такого проекта нужно отдельно установить, кто обновляет сертификат на внешнем узле и кто обслуживает соединение с исходным сервером.

Третий контроль — уведомления о неудачах. Редакционная рекомендация: назначить ответственного и проверять, что сообщение о сбое дойдёт до человека, способного его исправить. Запись в журнале сама по себе не гарантирует реакции. Для небольшого проекта достаточно понятного канала уведомлений и короткой инструкции, где искать причину.

Почему продление может перестать проходить

При выпуске сертификата ACME-клиент подтверждает управление доменом. В варианте HTTP-01 удостоверяющий центр проверяет специальный файл по HTTP; в DNS-01 — TXT-запись в DNS. Эти способы подробно описаны в документации Let’s Encrypt. У них разные зависимости, которые следует учитывать при изменениях инфраструктуры.

Например, после переноса сайта стоит проверить, остался ли доступным путь проверки HTTP-01. Для DNS-01 — что автоматизация по-прежнему может создавать нужную запись у DNS-провайдера. Наличие работающего HTTPS сегодня ещё не показывает, что следующая проверка владения доменом пройдёт успешно.

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

Что делать владельцу сайта на WordPress или WooCommerce

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

Для интернет-магазина стоит отдельно проверить все домены, через которые проходит покупатель: основной сайт, платёжные переходы и используемые поддомены. Это рекомендация по организации проверки, а не требование немедленно менять сертификаты. У разных адресов могут оказаться разные владельцы инфраструктуры.

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

Что можно сделать уже в октябре

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

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