Срок действия SSL сократили до 200 дней: почему сертификаты теперь нужно обновлять автоматически

Ещё недавно компания могла выпустить SSL-сертификат почти на год, поставить напоминание в календаре и вернуться к вопросу перед истечением срока. Для небольшого сайта такая схема выглядела вполне рабочей.

С 15 марта 2026 года ситуация изменилась. Максимальный срок действия новых публично доверенных TLS-сертификатов сократился с 398 до 200 дней. Следующий этап уже запланирован: с 15 марта 2027 года предел составит 100 дней, а с 15 марта 2029-го — 47 дней. Это закреплено в Baseline Requirements CA/Browser Forum — отраслевых требованиях, которым следуют удостоверяющие центры и участники экосистемы публичной Web PKI.

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

Если сертификат вовремя не обновился, проблема возникает не только у системного администратора. Пользователь может не попасть на сайт, приложение — потерять соединение с API, а рекламный трафик — прийти на ресурс, которому браузер или другой клиент не может установить доверенное HTTPS-соединение. Для интернет-магазина или сервиса это уже вопрос продаж, заявок и доступности проекта.

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

200 дней — это не новый срок для каждого SSL-сертификата

Здесь есть важный нюанс, который часто теряется в заголовках.

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

Хороший пример — Let’s Encrypt. Его стандартные сертификаты на момент подготовки материала имеют срок действия 90 дней, то есть и до нового ограничения укладывались в него с большим запасом. Более того, с 13 мая 2026 года Let’s Encrypt предлагает для раннего тестирования профиль tlsserver, выпускающий сертификаты на 45 дней. Для основного профиля дальнейшее сокращение запланировано поэтапно: до 64 дней в феврале 2027 года и до 45 дней в феврале 2028-го.

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

Почему отрасль вообще сокращает сроки

Короткий срок действия сертификата кажется неудобством только в модели, где каждый выпуск выполняется человеком.

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

CA/Browser Forum отдельно указывает, что сокращение сроков уменьшает период, в течение которого некорректный, устаревший или потенциально скомпрометированный сертификат может оставаться действующим. Более короткие циклы также упрощают переход на новые криптографические требования и снижают зависимость экосистемы от механизмов отзыва сертификатов.

Но есть и второй эффект: новые правила фактически подталкивают инфраструктуру к автоматизации управления сертификатами. В самом обосновании изменения CA/Browser Forum отмечает ожидаемое развитие более стабильных механизмов автоматизированной выдачи, замены и ротации сертификатов.

Для бизнеса это важнее конкретного числа «200». Срок ещё будет сокращаться.

Почему календарное напоминание больше не решает проблему

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

Кроме основного сайта могут существовать поддомены, API, панели управления, мобильный backend, webhook-endpoints, тестовые среды, балансировщики, CDN и другие публичные сервисы.

Часть сертификатов может обслуживаться панелью управления, часть — Certbot, часть — облачной платформой или отдельным удостоверяющим центром.

В такой инфраструктуре слабое место — не срок сертификата, а отсутствие единого процесса.

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

При цикле в 398 дней подобная ошибка могла не проявляться больше года. При 100 или 47 днях процессы будут проверяться значительно чаще.

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

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

проверка необходимости обновления → подтверждение контроля над доменом → получение нового сертификата → установка → применение новой конфигурации сервисом → проверка результата → мониторинг.

Если один из этапов требует ручного действия, автоматизация остаётся частичной.

Для сайтов на Linux один из распространённых вариантов — Certbot. Его актуальная документация прямо указывает, что большинство способов установки уже предусматривают автоматическое продление. Команда certbot renew проверяет установленные сертификаты и обновляет те, для которых наступил период продления. В современных версиях Certbot сертификат считается готовым к обновлению, когда остаётся меньше трети его срока действия.Где разместить: после раздела об автоматическом продлении.Задача изображения: показать, что автоматизация SSL состоит не из одной команды.Что изобразить: замкнутый цикл из шести блоков: «Контроль срока» → «Проверка домена» → «Выпуск» → «Установка» → «Применение» → «Проверка и мониторинг» → возврат к первому блоку. Красным маркером выделить возможные точки отказа: DNS, права доступа, конфигурация веб-сервера, отсутствие перезагрузки/перечитывания сертификата.Текст на изображении: «Автоматизация — это весь цикл»ALT: Схема автоматического обновления TLS-сертификата от проверки срока до мониторинга результата.Подпись: Получить новый сертификат недостаточно — приложение или веб-сервер должны начать использовать его, а результат необходимо проверить.

Проверить механизм можно без реального перевыпуска:

sudo certbot renew --dry-run

На системах с systemd стоит также проверить наличие соответствующего таймера:

systemctl list-timers | grep certbot

Конкретная схема зависит от способа установки Certbot и операционной системы. Поэтому создавать дополнительную cron-задачу вслепую не стоит: сначала нужно выяснить, какой механизм уже настроен. В официальной документации Certbot для этой проверки рекомендуются системные cron-задачи и systemd timers.

Отдельного внимания требуют сертификаты, изначально полученные Certbot через режим --manual: сами по себе они автоматически не продлеваются, если не настроены специальные authentication hooks.

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

Где автоматизация чаще всего ломается

Одна из распространённых ошибок — проверять только основной домен. Сертификат example.ru может исправно обновляться, а менее заметный api.example.ru или служебный поддомен — нет.

Другая проблема возникает после изменения DNS или архитектуры сайта. Например, домен переводят на CDN, меняют балансировщик или веб-сервер, а механизм проверки домена остаётся настроенным под старую конфигурацию.

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

Особенно внимательно следует относиться к ручной DNS-проверке. Если для подтверждения владения доменом человек каждый раз должен самостоятельно создавать TXT-запись, полностью автоматическим такой процесс назвать нельзя.

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

Что бизнесу и digital-команде стоит проверить уже сейчас

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

Для начала имеет смысл составить реестр публичных HTTPS-точек: основные домены, поддомены, API, панели, интеграционные endpoints и другие сервисы. Для каждого нужно понимать, где находится сертификат, кем он выпускается и как обновляется.

Затем стоит провести тест продления. Наличие cron или systemd timer ещё не доказывает, что сертификат действительно получится перевыпустить после изменений DNS, firewall, веб-сервера или прав доступа.

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

Что проверитьПочему это важноКакие домены и поддомены используют TLSПозволяет не забыть API и вспомогательные сервисыКто выпускает каждый сертификатУбирает неопределённость между разработчиком, хостером и администраторомЕсть ли автоматическое продлениеРучной процесс будет становиться всё менее устойчивымМожно ли выполнить тестовое продлениеПомогает обнаружить проблемы до реального срока обновленияПрименяется ли новый сертификат сервисомСам факт успешного выпуска ещё не означает успешное обновлениеЕсть ли мониторинг срока и ошибокДаёт время на устранение сбоя до окончания действия сертификата

Для проектов без собственного администратора имеет смысл заранее определить, кто отвечает за этот процесс. Если обслуживание инфраструктуры передано провайдеру, нужно проверить границы услуги. В AdminVPS, например, отдельно описано администрирование серверов, включающее настройку, мониторинг и поддержку серверной инфраструктуры.

200 дней — только первый этап

Главная ошибка сейчас — воспринимать изменение как разовую административную задачу: заменить прежнее ежегодное напоминание на напоминание раз в несколько месяцев.

Расписание CA/Browser Forum показывает обратное. 200 дней — переходный этап. Уже в марте 2027 года максимальный срок сократится до 100 дней, а в 2029 году — до 47.

При такой модели сертификат становится не документом, который периодически «продлевают», а автоматически ротируемым элементом инфраструктуры.

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

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