Если срок действия сертификатов вы отслеживаете по календарю Outlook, напоминаниям в Jira или таблице Excel — новости вам не понравятся.

15 марта 2026 года максимальный срок жизни публичного TLS‑сертификата официально сократили с 398 до 200 дней. Это не «планируется» и не «обсуждается», это уже действующая норма. Дальнейшее сокращение будет идти по расписанию: 100 дней в 2027-м и 47 в 2029-м. И вот в чём загвоздка: в инфраструктурах среднего и крупного размера ручной процесс управления жизненным циклом сертификатов с основным инструментом в виде эксельной таблички такую частоту ротации не вывезет. Точнее вывезет, если ваш ответственный за PKI готов сидеть в этой табличке круглосуточно и никогда не ходить в отпуск, либо вы готовы нести дополнительные затраты на поиск и найм дополнительных специалистов.

Так что же случилось, почему это неприятнее, чем звучит на первый взгляд, и что стоит успеть сделать за оставшееся время.

Кто это всё придумал и кто голосовал

Основным инициатором изменений стала Apple, ключевым спонсором выступила Sectigo. Рассматривались два варианта ограничений: 45 дней (позиция Apple) и 90 дней (позиция Google). Кто «победил» вы уже знаете.

Итоговое решение принимал CA/Browser Forum (отраслевой консорциум производителей центров сертификации и браузеров). Голосование прошло с 4 по 11 Апреля 2025 года.: Результаты: 25 «за» и ни одного «против» со стороны CA (при 5 воздержавшихся, в т.ч. Entrust и TWCA), плюс единогласные 4 «за» от браузеров (Apple, Google, Microsoft, Mozilla) — это данные официального протокола голосования CA/Browser Forum. Представители TWCA озвучили в своей рассылке, что сокращение максимальных сроков действия сертификатов со 100 до 47 дней кажется им слишком резким и что ущерб от фишинга пока никто не сравнивал с ущербом от таких сроков ротации. Возражение разумное, но его не хватило, чтобы что‑то изменить. Ну и голосовать против они не стали.

Сам таймлайн

Ниже — график перехода к новым срокам. Он пригодится при планировании бюджета на автоматизацию.

Число перевыпусков в год в таблице выше — не наивное «365 / срок действия». На практике сертификаты продлевают заранее, а не в последний день, поэтому реальных перевыпусков ощутимо больше: для 100-дневного срока это около 5 в год, а не 3–4, для 47-дневного — около 12, а не 8.

Считаем в часах и нервах

Возьмём для примера инфраструктуру на 1000 внешних TLS‑сертификатов — среднего размера банк или ритейлер.

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

При переходе на 47-дневный цикл это уже около 12 000 перевыпусков в год, порядка 33 операций в день, без учёта праздников и отпусков.

Похожие расчёты мы проводили и в рамках собственных проектов. Для инфраструктуры из 2500 систем на горизонте трёх лет (2027–2029 годы) сравнение двух моделей управления сертификатами показывает следующее:

При ручном управлении нагрузка растёт нелинейно: если в 2027 году это около 37 500 рабочих часов, то уже в 2029-м, с учётом перехода на 47-дневные сертификаты и роста числа систем, — порядка 108 900 часов. При автоматизации число ручных операций по выпуску и обновлению сертификатов сокращается до нуля, а совокупные затраты на лицензии, внедрение и сопровождение дежурной группой оказываются ниже прямых затрат на ручное администрирование — и это без учёта стоимости простоев и репутационных рисков, которые сложно оценить заранее.

На уровне отдельных операций эффект ещё нагляднее: ручной запрос сертификата через подрядчика занимает 2–3 дня против 5 минут в автоматическом режиме, ручная установка на сервер — 1–2 часа против нескольких минут, ручное отслеживание сроков действия — 10–20 минут на сертификат против практически мгновенного автоматического мониторинга.

Кроме прямых трудозатрат растёт и операционный риск. Сертификаты, о существовании которых никто не помнит, продолжают действовать до истечения срока и создают риск незапланированного простоя. На практике нередко встречается ситуация, когда сертификат, изначально выпущенный для тестового контура, со временем становится частью боевой инфраструктуры, а информация об этом нигде не фиксируется. При годовом цикле обновления такие случаи проявлялись в среднем раз в год; при переходе на 47-дневный цикл частота подобных инцидентов увеличивается кратно — до 8–12 раз, если ориентироваться на оценку CA/Browser Forum и данные нашего собственного анализа.

Ponemon Institute в опросе для DigiCert зафиксировал, что 51% организаций не ведут полную инвентаризацию всех своих сертификатов, а столько же не знают точное число выпущенных сертификатов в принципе. Иными словами, описанный выше сценарий не гипотетический, а статистически распространённый.

Let's Encrypt переходит на 45-дневные сертификаты уже к февралю 2028 года — на год раньше общего дедлайна CA/Browser Forum. Это даёт возможность протестировать процессы автоматизации на реальной инфраструктуре заранее, до наступления более жёстких сроков.

Что это ломает в архитектуре

Формально изменился один параметр спецификации. По сути это означает конец модели «выпустили сертификат, установили и забыли на длительный срок». На смену ей приходит конвейер: нашли все сертификаты → завели в инвентарь → настроили автоперевыпуск (у нас в Clearway за это отвечает ЕСАУС) → раскатали на конечные точки → настроили мониторинг и оповещения (это уже зона СМИОК). Это и есть CLM (certificate lifecycle management). Любой ручной шаг, оставшийся в этой цепочке, становится точкой отказа — и с переходом на 47-дневный цикл эта точка будет проверяться на прочность не раз в год, а до двенадцати раз.

Наиболее уязвимые места:

• Wildcard и SAN. Под лимит подпадают целиком. Один wildcard‑сертификат на весь домен означает, что при его истечении разом выходит из строя всё, что на нём было завязано, если процесс не полностью автоматизирован.

• Оборудование без поддержки ACME. Балансировщики, аппаратные VPN‑шлюзы и другое оборудование, не обновлявшееся годами. Сертификаты на нём тоже истекут, а модернизация такого оборудования требует отдельного планирования.

А что у нас, в России

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

С 4 мая 2026 года CA/Browser Forum сделал проверку по санкционным спискам не рекомендацией, а обязательным требованием для всех удостоверяющих центров. Итог не заставил себя ждать: GlobalSign, у которого было около 90% коммерческого рынка западных сертификатов в России, с 13 июня начал принудительный отзыв сертификатов у российских компаний — под ударом, по оценкам участников рынка, до 20 тысяч доменов второго уровня, а с учётом поддоменов счёт идёт на куда большие цифры.

Тут стоит сразу закрыть вопрос про «90% рынка» — цифра точная, но не про всё сразу. Минцифры оперирует другой оценкой — «не более 5%», и оба числа справедливы одновременно: 5% — это доля GlobalSign от рунета в целом, а 90% — от коммерческого сегмента именно западных сертификатов. Спор не про то, кто врёт, а про то, что считать знаменателем — но легче от этого не становится ровно никому.

Let's Encrypt тоже переписал пользовательское соглашение: сертификаты для российских госструктур и лиц под санкциями теперь вне закона, для остальных формулировка мягче («может выдавать»), но твёрдых гарантий никто не даёт.

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

Ответ на это уже есть, хоть и не идеальный. С 2022 года работает Национальный УЦ Минцифры: сертификат можно получить бесплатно за три рабочих дня через Госуслуги. С августа 2025 через КриптоПро тот же УЦ выпускает ГОСТ TLS‑сертификаты. Загвоздка в том, что этот корень по умолчанию не входит в доверенные списки Chrome, Safari и Edge — то есть часть пользователей, особенно из‑за рубежа, увидит красивое предупреждение о небезопасном соединении, пока не установит российский корневой сертификат вручную. Практика показывает, что этим мало кто занимается:

по свежей статистике даже среди государственных доменов на российский TLS перешли около 7% — и это те, кому переход настоятельно рекомендован сверху. Готового рецепта, получается, нет даже там, где он вроде бы обязателен.

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

Что успеть сделать до 2027 года: чек‑лист

Ниже — пошаговый план на ближайшие месяцы. Пригодится и как рабочий чек‑лист для команды, и как аргумент при обосновании бюджета на автоматизацию.

1. Проведите полную инвентаризацию. Тестовые стенды, IoT‑устройства, оборудование, которое давно не проверялось. Сертификаты, не обнаруженные на этом этапе, впоследствии проявят себя в виде инцидента.

2. Проверьте поддержку ACME и ARI на всём, что терминирует TLS: балансировщики, веб‑серверы, CDN. Там, где поддержки нет, заранее решите, чем заменить.

3. Разверните CLM с автоперевыпуском, инвентаризацией и полноценной отчётностью. Учёт в Excel или точечные скрипты, написанные для разовых задач, не обеспечивают достаточной надёжности при таком объёме операций.

4. Переведите валидацию доменов на автоматику (DNS-01, HTTP-01). При десятидневном окне DCV в 2029-м ручная валидация физически не будет успевать.

5. Осуществите переход Let's Encrypt на 45-дневные сертификаты (уже с февраля 2028 года) как возможность заранее протестировать процессы автоматизации на реальной инфраструктуре.

6. Подготовьте запасной трек через Национальный УЦ Минцифры для сервисов с повышенным санкционным риском: заявка через Госуслуги (готово за три рабочих дня) либо, с декабря 2025 года в тестовом режиме, автоматический выпуск через ACMEv2. Не панацея: доверие зарубежных браузеров такой сертификат не гарантирует, но это страховка на случай внезапного отзыва зарубежного. При наличии ACME этот трек проще встроить в общий CLM‑конвейер, а не вести отдельным ручным процессом.

Итог

Сокращение сроков жизни сертификатов — не абстрактное изменение в отраслевых стандартах, а фактор, который в ближайшие два‑три года напрямую скажется на устойчивости ИТ‑инфраструктуры. Компании, которые продолжат управлять сертификатами вручную, почувствуют кратный рост трудозатрат уже в 2027 году, а к 2029-му — кратно возросшие издержки и риски сбоев, вызванных банальной человеческой невнимательностью.

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