Как подготовиться к SSL-сертификатам на 199 дней

С 24 февраля 2026 года публично доверенные TLS-сертификаты будут выпускаться с максимальным сроком действия около 199 дней, и в последующие годы этот потолок продолжит снижаться. Это руководство объясняет, что решение CA/Browser Forum меняет на практике, что происходит с многолетними покупками сертификатов и как подготовиться, если вы управляете 1, 10 или 100 сертификатами. Оно написано для администраторов и разработчиков, которые сами отвечают за продление.

Что меняется 24 февраля 2026 года

CA/Browser Forum является отраслевой организацией, в которой удостоверяющие центры и разработчики браузеров согласуют правила публичного TLS. Она проголосовала за поэтапное сокращение максимального срока действия публичных сертификатов. Первый этап вступает в силу 24 февраля 2026 года: с этой даты ни один публично доверенный сертификат не может быть выпущен со сроком действия дольше примерно 199 дней, то есть около 6.5 месяцев. Согласованный график продолжается дальше вниз: около 100 дней в 2027 году и примерно 47 дней к 2029 году. По тому же графику сокращаются и периоды повторного использования доменной валидации, поэтому сохраненные проверки тоже будут истекать быстрее.

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

Многолетние покупки сохраняются, файл сертификата нет

Коммерчески ничего не исчезает. Вы по-прежнему можете купить сертификат на один, два или три года, и для OV и wildcard продуктов длинные сроки обычно остаются дешевле в пересчете на год. Меняется механика. Заказ превращается в подписку, а файл, установленный на вашем сервере, является лишь одним краткосрочным выпуском внутри этой подписки, действительным не более 199 дней. В середине срока вы запрашиваете перевыпуск, удостоверяющий центр без доплаты подписывает свежий сертификат в рамках того же заказа, и вы его устанавливаете. Приватный ключ может остаться прежним, но менять его при каждом перевыпуске полезнее.

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

Почему ручной перевыпуск не масштабируется

С одним сертификатом ручной процесс терпим: сгенерировать CSR, пройти валидацию, скачать файл, установить его, перезагрузить веб-сервер. При 199 днях это происходит два или три раза в год вместо одного. С 10 сертификатами вы получаете 20-30 ручных перевыпусков в год, и каждый из них дает шанс вставить не тот файл, забыть промежуточный сертификат или пропустить один сервер в кластере. Со 100 сертификатами и лимитом 47 дней в 2029 году это примерно 800 перевыпусков в год, то есть около 3 в каждый рабочий день. Ни одна команда не делает это надежно вручную.

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

Автоматизация становится нормой по умолчанию

Разумный ответ: передать выпуск и продление машине. Есть два реалистичных пути:

• ACME: протокол, на котором работает Let's Encrypt и который для DV и даже OV продуктов предлагают и некоторые коммерческие удостоверяющие центры. Клиенты вроде certbot или acme.sh продлевают сертификаты задолго до истечения и перезагружают ваши сервисы.
• Инструменты провайдера: если вы покупаете сертификаты через хостинг или SSL-провайдера, используйте его API перевыпуска или управляемую установку вместо ручного скачивания.

Минимальная настройка ACME на веб-сервере с Debian или Ubuntu:

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

# убедитесь, что таймер продления активен и продление реально работает
systemctl list-timers | grep certbot
certbot renew --dry-run

Для wildcard сертификатов используйте проверку DNS-01, в идеале с записью _acme-challenge, делегированной через CNAME в зону, в которую ваша автоматизация имеет право писать. Мониторинг держите отдельно от инструмента продления: cron-задача или внешняя проверка, которая предупреждает, когда какому-либо сертификату остается меньше 14 дней, ловит те сбои, о которых сам инструмент не сообщает.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -enddate

Чек-лист подготовки по размеру парка

1 сертификат

• Запишите текущую дату истечения и поставьте напоминания за 30 и за 14 дней до нее.
• Если вам достаточно DV, переходите на ACME уже сейчас и больше не думайте о продлениях.
• Если у вас платный OV или wildcard сертификат, проведите один тестовый перевыпуск в панели провайдера уже сегодня, чтобы первый обязательный перевыпуск в середине срока не стал сюрпризом.

Около 10 сертификатов

• Составьте инвентаризацию: домен, дата истечения, где сертификат установлен, кто за него отвечает, как проходит валидация.
• Переведите на ACME каждый сертификат, который может быть DV, ручную обработку оставьте только там, где политика требует OV.
• Добавьте внешний мониторинг сроков для всего списка, а не отдельные crontab на каждом сервере.
• Стандартизируйте один метод валидации на домен, валидация через DNS лучше всего переживает переезды серверов.

100 и более сертификатов

• Относитесь к сертификатам как к сервису: центральная инвентаризация, в идеале сверенная с логами Certificate Transparency, чтобы ничто, выпущенное в обход вашего процесса, не осталось незамеченным.
• Уберите все ручные пути выпуска, сертификат, который выпустила не автоматизация, является багом.
• Делегируйте зоны _acme-challenge, чтобы DNS-01 работал без передачи автоматизации полного контроля над DNS.
• Оповещения за 21, 14 и 7 оставшихся дней, у каждого оповещения свой ответственный.
• Отрепетируйте лимит 2027 года уже сейчас: если ваш процесс сегодня не справляется со 100-дневными сертификатами, почините его до того, как это станет обязательным.

Что делать дальше

Эти изменения сильнее всего наказывают за откладывание: 24 февраля 2026 года само по себе ничего не сломается, но первый забытый перевыпуск в середине срока после этой даты положит сайт. Если вы покупаете коммерческие сертификаты, посмотрите наши SSL-сертификаты, во всех тарифах перевыпуск в середине срока бесплатен в течение всего оплаченного периода. А если вы не хотите поддерживать цикл продления сами, наш сервис автоматизации SSL настроит выпуск по ACME, развертывание и мониторинг сроков на ваших серверах и будет поддерживать их работу.