SSL certificate hell: как автоматизировать управление жизненным циклом цифровых сертификатов

Три часа ночи, воскресенье. «Пачка» уведомлений от системы мониторинга в почте и Telegram. Mission-critical система «лежит», потому что истёк TLS-сертификат, который упустили из вида и не включили в «эксельный» реестр.

Ситуация знакома? Тогда эта статья для вас. Разберём, почему вопросы управления цифровыми сертификатами резко обострились, какие классы решений есть на рынке, и почему «просто поставить cert-manager» — это не всегда финал истории.

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

Мир PKI изменился кардинально. Ещё 8-10 лет назад основная масса сертификатов приходилась на веб-серверы (TLS для публичных сайтов), подпись кода и S/MIME для почты. Сегодня мы наблюдаем взрывной рост числа технологических (non-public) сертификатов — их используют серверы, сервисы, контейнеры и микросервисы для взаимного удостоверения подлинности.

Основные драйверы такого роста:

Компоненты корпоративной инфраструктуры как субъекты ИБ. В настоящий момент подавляющее большинство элементов инфраструктуры являются полноправными субъектами информационного обмена, требующими собственных X.509-удостоверений.

Zero Trust и mTLS. Периметровая модель безопасности показала свою неэффективность в современных распределенных средах, и на смену ей пришла концепция Zero Trust («никогда не доверяй, всегда проверяй»). При взаимной аутентификации (mTLS) каждый субъект информационного обмена имеет собственный сертификат. Количество необходимых сертификатов растёт пропорционально количеству взаимодействующих субъектов.

Kubernetes и service mesh. Каждый Pod и каждый sidecar Istio/Linkerd/Consul — потенциальный держатель отдельного короткоживущего сертификата. Решение, построенное на современной микросервисной архитектуре зачастую требует выпуска в десятки и сотни раз большего количества сертификатов, чем классическое монолитное приложение с аналогичной бизнес-логикой.

Сокращение сроков жизни публичных сертификатов. В апреле 2025 года ЦС/Browser Forum принял решение о поэтапном сокращении максимального срока действия TLS-сертификатов: 398 дней (до февраля 2026) → 200 дней (март 2026) → 100 дней (март 2027) → 47 дней (март 2029), с параллельным ужесточением сроков переиспользования проверки владения доменом. Аналогичные сроки объявили GlobalSign и Let`s Encrypt (у последнего — вплоть до 45 дней уже в 2026 году для ранних адоптеров). Данный факт приведет к 8–12-кратному росту операционной нагрузки и расходов на перевыпуск сертификатов к 2029 году по сравнению с 2025-м.

Отдельно стоит выделить драйвер, специфичный для российского рынка — отзыв сертификатов зарубежных удостоверяющих центров. С 13 июня 2026 года японский GlobalSign — крупнейший коммерческий центр сертификации, продолжавший полноценно работать с российскими компаниями после 2022 года (около 90% коммерческого сегмента внешних сертификатов в РФ) — начал принудительный отзыв ранее выданных SSL-сертификатов у ряда российских организаций. Формальная причина — новые требования ЦС/Browser Forum об обязательном учёте международных санкционных списков при выдаче и обслуживании сертификатов. Одновременно Let`s Encrypt ужесточил пользовательское соглашение, запретив выдачу сертификатов подсанкционным лицам, организациям и госструктурам РФ. По оценкам опрошенных экспертов, процесс носит волновой характер и далёк от завершения: отзывы будут продолжаться по мере расширения санкционных списков и истечения сроков действия уже выпущенных сертификатов, а реальный масштаб последствий будет проявляться постепенно.

Минцифры уже предупреждало, что из-за отзывов часть российских сайтов может некорректно открываться в зарубежных браузерах (Chrome, Safari, Edge), а соединение — отображаться как небезопасное. Наиболее уязвимы мобильные приложения с certificate pinning и встроенными WebView-компонентами: без экстренного обновления они рискуют полностью потерять связь с серверами. Формальная альтернатива — переход на сертификаты Национального удостоверяющего центра (НЦС) Минцифры. Однако она сама создаёт эксплуатационную сложность. Подавляющее большинство зарубежных браузеров и ОС по умолчанию не доверяют корню НЦС, что требует установки сертификатов доверенных корневого и промежуточного ЦС на АРМ и мобильные устройства, либо построения гибридных схем доверия.

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

«TLS expired — here lies the service»

История знает достаточно случаев, когда истёкший или неправильно установленный сертификат останавливал целые сервисы: сбой Starlink в апреле 2023 года (глобальная потеря связи абонентских терминалов из-за просроченного сертификата наземной станции), блокировка мобильного банкинга Bank of Ireland в день зарплаты (июнь 2023), сбой аутентификации Microsoft Teams/SharePoint из-за неверно установленного сертификата (сентябрь 2023), а также два отдельных инцидента в системах расчётов Bank of England (январь и июль 2024) — во втором случае из-за истечения TLS-сертификата на несколько часов была остановлена работа платёжной системы с годовым оборотом свыше 6 трлн долларов. Список кейсов можно продолжать довольно долго…

По данным отраслевых опросов, более 70% организаций сталкивались с инцидентами, связанными с сертификатами, хотя бы раз за последние два года. Когда сертификатов 15 — ручной контроль успешно работает. Когда их 1500 (а в крупных предприятиях счёт сертификатам идёт на десятки и сотни тысяч) – ручное управление это неудачная попытка формализовать операционный хаос, который обязательно приведет к негативным последствиям, это просто вопрос времени.

Три класса решений автоматизации

Все инструменты автоматизации жизненного цикла сертификатов можно разделить по уровню зрелости на три категории.

Безагентные решения (SCEP, EST, ACMEv2, MS-WSTEP)

Принцип работы: устройство обращается к центру сертификации по стандартному протоколу как правило без установки дополнительного ПО.

• SCEP (Simple Certificate Enrollment Protocol, RFC 8894) — стандарт для автоматической выдачи сертификатов в enterprise-среде: сетевое оборудование (Cisco, Juniper, Aruba), MDM/UEM-платформы, VPN-клиенты и IoT-устройства. SCEP не определяет собственный механизм отзыва сертификатов: функция GetCRL не специфицирована детально, отзыв полностью делегируется внешним механизмом (CRL/OCSP) со стороны ЦС. При компрометации клиент продолжает работать до истечения срока сертификата, если ЦС не реализует отзыв корректно. Существует уязвимость обработки CSR — подстановка номера конфигурации в структуре подписанного запроса (MITM-атака на динамический SCEP).

• EST (Enrollment over Secure Transport, RFC 7030) — стандарт для автоматической выдачи сертификатов поверх защищённого TLS-канала, разработанный как более безопасная альтернатива SCEP. Протокол работает поверх HTTPS и использует TLS для шифрования и аутентификации. Поддерживает клиентскую аутентификацию (mTLS) в обоих направлениях и позволяет подписывать запросы с помощью ранее выпущенных сертификатов, что делает его пригодным для верификации устройств и сценариев mTLS. Протокол менее распространён, чем ACME и SCEP, но поддерживается рядом ЦС и MDM-платформ.

• ACMEv2 (RFC 8555/8737) — де-факто стандарт автоматизации выпуска сертификатов для публичных веб-сервисов на таких ЦС как Let’s Encrypt, Google Trust Services, ZeroSSL и ряд других. Протокол аутентифицирует аккаунт и подтверждает владение доменом через challenge (HTTP-01, DNS-01, TLS-ALPN-01), а не удостоверяет конкретное устройство как субъект сертификата. По этой причине классический ACME в чистом виде не предназначен для сценариев клиентской аутентификации (например, выдача сертификатов с EKU=client auth полностью прекращена Let`s Encrypt 08.07.2026) и плохо применим для mTLS, где требуется удостоверение личности клиента, а не контроль над доменом. При этом паттерны, заложенные в ACME (автовыпуск, короткие TTL, ротация) лежат в основе современных решений client identity, в которых субъект удостоверяется attestation, а не DNS-челленджем.

• MS-WSTEP (Web Services for Trust Provisioning) – протокол, основанный на стандартах веб-сервисов (WS-Trust), который в инфраструктуре Microsoft реализован через связку двух ролей: Certificate Enrollment Policy (CEP) и Certificate Enrollment Service (CES). Основное назначение: обеспечение автоматического выпуска (autoenrollment) и ручного запроса сертификатов. Протокол был спроектирован под нужды Windows-клиентов и его использование на альтернативных ОС является нетривиальной задачей и практически невозможно. Связка CEP и CES известна своей «хрупкостью». Ошибки аутентификации между клиентами CES, ЦС и клиентами крайне сложно диагностируются.

• NDES (Network Device Enrollment Service) – служба в составе Active Directory Сertificate Services (AD CS), которая играет роль шлюза и реализует протокол SCEP. Основное назначение: автоматическая выдача сертификатов устройствам, не включенным в домен (сетевое оборудование, MDM, VPN-клиенты) через HTTP/HTTPS. Решение полностью привязано к стеку Microsoft: требует развёртывание роли NDES на Windows Server, интеграцию с AD CS, настройки специфических шаблонов, что делает его малоприменимым вне инфраструктуры Microsoft. Сам сервис NDES выступает узким горлом и единой точкой отказа — он агрегирует все запросы от устройств, и его недоступность (сбой службы, перегрузка, обновление, отзыв учётных данных службы) останавливает выпуск сертификатов для всей сети одновременно.

Общий вывод по категории. Ни один из рассмотренных вариантов (SCEP, EST, ACMEv2, MS-WSTEP, NDES) не обеспечивает полноценной аутентификации устройства, не передаёт метаданные о его состоянии (версия ОС, патчи, конфигурация) и не предоставляет механизм инвентаризации — следовательно, наличие теневой PKI (Shadow PKI) такими протоколами не обнаруживается. Они пригодны для простых сценариев массовой автоматической выдачи сертификатов, но критически недостаточны для архитектур Zero Trust и масштабного mTLS на уровне предприятия, где требуется удостоверение личности устройства, актуальность его состояния и полная наблюдаемость его сертификатов.

Псевдоагентные решения (CertMonger, CertBot, cert-manager, Windows Auto Enrollment)

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

• Certbot — референсный ACME-клиент от EFF с нативной интеграцией в Apache/Nginx и автопродлением через systemd/cron. Заточен под классические веб-серверы и сертификаты публичных ACME-ЦС (например, Let’s Encrypt). Не предназначен для выпуска и управления клиентскими сертификатами (т.е. не закрывает mTLS-связку целиком). С корпоративными ЦС работает только в том случае, если те поддерживают протокол ACME;

• acme.sh — лёгкий shell-скрипт без зависимостей, существенно шире Certbot по поддержке DNS-провайдеров для DNS-01 (100+ плагинов для Cloudflare, Route53, Azure DNS и др.). Не имеет GUI. В корпоративную инфраструктуру интегрируется через интерфейс ACME (включая корпоративные ACME-ЦС) и путём встраивания в CI/CD, контейнеры (Docker/k8s), а также через кастомные DNS-хуки для внутренних DNS-сервисов. Автопродление реализовано через cron/systemd-таймеры, а не автономным демоном. Не предоставляет готовых интеграций с legacy-ЦС (SCEP/EST), централизованного управления, GUI и нативной интеграции с PKI/HSM.

• cert-manager — Kubernetes-контроллер, управляющий сертификатами через CRD (Certificate, Issuer, ClusterIssuer). Поддерживает различные механизмы интеграции с ЦС: по протоколу ACME (Let’s Encrypt, внутренние ACME-серверы), через нативные API продуктов HashiCorp Vault и Venafi, а также умеет выступать простейшим локальным ЦС (через Issuer типа ЦС, использующий закрытый ключ из Secret). Полностью привязан к экосистеме Kubernetes — вне кластера не работает и ориентирован на кластерные сценарии выдачи/продления. Не реализует встроенный отзыв по ACME (при удалении сертификат просто перестаёт продлеваться и истекает естественным образом), хотя для Vault/Venafi отзыв доступен через их API. Локально собирает и обрабатывает кластерные метаданные и экспортирует метрики (Prometheus).

• Certmonger — системный демон Linux для управления жизненным циклом сертификатов (выпуск, мониторинг и автоматическое продление). Исторически создан для экосистемы FreeIPA и ЦС Dogtag с глубокой интеграцией в стек Red Hat, но сегодня доступен из коробки в большинстве дистрибутивов (Debian, Ubuntu, Arch). Управление — только через CLI (getcert) и шину D-Bus, GUI отсутствует. Является полноценным ACME-клиентом (ACMEv2), работающим как с публичными ЦС (Let`s Encrypt), так и с внутренними (включая встроенный ACME-сервер современных версий FreeIPA). Также сохраняется поддержка SCEP и проприетарных API Dogtag.

• Windows Auto Enrollment + GPO — механизм автоматической выдачи сертификатов компьютерам и пользователям в Active Directory через шаблоны AD CS и групповые политики. Работает только в экосистеме Windows/AD CS (требует развёрнутой роли AD CS и настроенных шаблонов + GPO), не является ACME-клиентом и не работает с внешними/публичными ЦС. При удалении компьютера из домена его сертификат не отзывается автоматически и остаётся действующим до конца своего срока. Отзыв нужно делать вручную (certutil -revoke), так как система умеет автоматически отзывать старые сертификаты только в момент их планового продления.

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

Как и в случае с протоколами выдачи (см. вывод по разделу 1), данные средства автоматизации не формируют полноценную машинную идентичность. Они запрашивают сертификаты вслепую, не собирая и не передавая метаданные о состоянии и комплаенсе самого устройства.

Из-за отсутствия единого центра управления каждый инструмент видит только тот парк сертификатов, который выдал сам. Это делает невозможной инвентаризацию «чужих» сертификатов и обнаружение теневой PKI (Shadow PKI). Иными словами, это разрозненные утилиты локальной автоматизации, а не системы полного жизненного цикла. Для реализации Zero Trust и сквозного контроля необходим централизованный слой (CLM), который объединит разрозненные контуры, обеспечит сбор метаданных об устройствах и предоставит единый механизм управления.

Агентные решения (Venafi, Keyfactor, AppViewX, ЦУГИ ЕСАУС, ЦУГИ ЕХС)

Принцип работы: на устройстве работает специализированный агент, который контролирует локальное хранилище ключей, собирает метаданные окружения, взаимодействует с центральным сервером управления и обеспечивает Proof of Possession закрытого ключа. Это единственный класс решений, предоставляющий единый управленческий контур для гетерогенных инфраструктур и обеспечивающий следующий функционал (список может быть не полным): централизованную инвентаризацию, распространение сертификатов доверенных корневых и промежуточных ЦС с контролем целостности, compliance-проверку окружения перед выпуском, доставку сертификата на конечную систему-потребитель, настройку конечной системы для использования обновленного сертификата, контроль подлинности данных в CSR, привязку сертификата к «месту рождения», работу с неизвлекаемыми ключами в TPM/HSM/смарт-картах и Key Recovery без передачи закрытого ключа по сети.

• Venafi — коммерческая платформа управления жизненным циклом доверия и сертификатов (Certificate Lifecycle Management, CLM). Фактически выступает Manager of Managers / control plane: централизованно обнаруживает, инвентаризирует, мониторит, продлевает и отзывает сертификаты, находящиеся под управлением Системы, а также за счет сетевого сканирования выявляет теневую PKI (Shadow PKI), обеспечивая инвентаризацию тех сертификатов, которые были выпущены в обход корпоративных процедур. Работает как оркестратор поверх существующих ЦС (AD CS, EJBCA, DigiCert, Sectigo) и криптопровайдеров, поддерживая интеграцию с Vault, ACME, EST, SCEP и Kubernetes. Отдаёт приоритет аутентификации и авторизации через роли, политики и интеграцию с SIEM, а также инвентаризации всех сертификатов — включая обнаружение неконтролируемых и просроченных. Недостатки: закрытое коммерческое ПО с высокой стоимостью и лицензированием; не является первичным источником данных (Source of Truth) о машинной идентичности; для проверки контекста и состояния устройств он опирается на интеграции с инфраструктурными системами (IAM, MDM, CMDB), а для криптографического выпуска — на подключённые ЦС; требует серьёзной конфигурации политик для полноценного Zero Trust. В настоящее время недоступен в РФ.

• Keyfactor — комплексная платформа управления цифровыми сертификатами (CLM) и PKI уровня предприятия, с сильным фокусом на масштабируемость, устройства и IoT. Охватывает весь жизненный цикл криптографии. В отличие от чистых CLM-решений, Keyfactor (после слияния с PrimeKey) предоставляет полный стек, включая собственный мощный ЦС (EJBCA), но при этом отлично работает как брокер для сторонних и облачных ЦС (через протоколы ACME, EST, SCEP). Платформа смещает фокус на строгую машинную идентичность, компенсируя «слепоту» базовых протоколов и обеспечивая сквозную наблюдаемость сертификатов вместе с контекстом устройства. Недостатки: высокая стоимость лицензирования Enterprise-уровня; требует развёртывания собственных агентов; сложность внедрения политик Zero Trust. В настоящее время недоступен в РФ.

• AppViewX – коммерческая платформа класса Сertificate Lifecycle Management (CLM) и PKI-as-a-Service, ориентированная на комплексную автоматизацию и оркестрацию выпуска, развёртывания, обновления и отзыва сертификатов в гетерогенных средах. Как и Venafi/Keyfactor, она выступает control plane (Manager of Managers), а не отдельным протоколом: AppViewX агрегирует и управляет множеством подключённых ЦС (AD CS, EJBCA, DigiCert, Sectigo, openssl, облачные ЦС), предоставляет интерфейсы для работы по стандартным протоколам ACME, EST, SCEP, а также напрямую интегрируется с инструментами класса Secrets Management (HashiCorp Vault) сводя их в единый контур управления. Ключевой упор сделан на визуальную оркестрацию процессов (No-Code/Low-Code автоматизацию) — платформа позволяет администраторам выстраивать сложные цепочки доставки сертификатов до подключённых систем (балансировщики F5, Citrix, AWS ALB, Kubernetes/Ingress, веб-фронтенды) без написания кастомных скриптов и ручного вмешательства. Недостатки: закрытое проприетарное ПО со значительной стоимостью лицензий и внедрения; эффективность напрямую зависит от качества настроенных политик и покрытия инфраструктуры. В настоящее время недоступен в РФ.

• ЦУГИ (Централизованное Управление Гетерогенными Инфраструктурами): Clearway ЦС + ЕСАУС + ЛКПС + СМИОК + ЕХС + СУУ СКЗИ 2.0 – российская экосистема CLM/Enterprise PKI + Secret Management от Клируэй Текнолоджис, которая по назначению и архитектуре выступает российским аналогом связки Venafi/Keyfactor/AppViewX + HashiCorp Vault, адаптированной под требования законодательства РФ. Это control plane: платформа централизованно управляет жизненным циклом сертификатов и ключей поверх собственного ЦС (Clearway ЦС) и/или сторонних ЦС, агрегируя их в единый контур. Ключевая особенность — поддержка российских криптографических алгоритмов (ГОСТ Р 34.10, ГОСТ Р 34.11) в дополнение к RSA и ECDSA, что критично для госсектора и критической инфраструктуры. Крупнейшая инсталляция продуктов Клируэй обеспечивает более 190 миллионов автоматических операций выпуска/обновления цифровых сертификатов в год силами команды из 2 (двух) человек. Ограничения: эффективность, как и в западных аналогах, зависит от качества настроенных политик, интеграций и покрытия всех источников сертификатов и секретов, требует развёртывания агентов/компонентов в инфраструктуре для доставки и установки сертификатов.

Заключение

Автоматизация жизненного цикла сертификатов перестала быть вопросом удобства — это вопрос устойчивости инфраструктуры. Сокращение сроков жизни публичных сертификатов до 47 дней к 2029 году, взрывной рост числа технологических non-public сертификатов, повсеместное внедрение mTLS в модели Zero Trust делают ручное управление физически невозможным уже в среднесрочной перспективе.

Выбор инструмента — это выбор класса решения, а не вопрос «что лучше». Certbot и промышленная агентная CLM-платформа не конкурируют друг с другом: они решают задачи разного масштаба. Для небольших и однородных сред open-source инструментов достаточно. Для enterprise-инфраструктуры с гетерогенным ландшафтом (Kubernetes, service mesh, bare-metal, требования по ГОСТ и аудиту) нужен управленческий контур поверх операционной автоматизации — единые политики выпуска, разграничение ролей ИБ/ИТ, сквозной аудит и защищённое хранение ключей.

В качестве примера такого управленческого контура на российском рынке можно привести линейку продуктов компании Клируэй Текнолоджис, построенных на единой платформе ЦУГИ (Clearway CA, ЕСАУС, ЕХС, ЛКПС, СУУ СКЗИ 2.0): она нацелена на покрытие всех типов объектов гетерогенной инфраструктуры — от серверов и рабочих станций на Linux, Windows и macOS до контейнеризированных нагрузок и кластеров Kubernetes с Service Mesh (Istio) — в рамках единого централизованного контура выпуска, продления, отзыва и доставки сертификатов, вне зависимости от типа инфраструктуры или используемых средств шифрования (RSA/ГОСТ). Такой подход снижает фрагментацию PKI-ландшафта, характерную для сценариев с разрозненными «встроенными» механизмами выпуска сертификатов (cert-manager, ACME-клиенты и т.п.), и оставляет за службой информационной безопасности контроль над политиками выпуска, аудитом, ролевой моделью доступа и мониторингом состояния сертификатов во всей организации. Разумеется, выбор конкретной платформы — вопрос отдельного сравнения под требования инфраструктуры, регуляторику и бюджет.

P.S. Почему для Kubernetes и Istio «просто cert-manager + istio-csr» — не финал истории

Отдельно стоит разобрать частое заблуждение: раз в кластере настроен cert-manager с ACME или локальным (In-cluster ЦС), вопрос автоматизации сертификатов закрыт. Это верно лишь для операционного слоя и лишь частично.

Cert-manager решает операционную, а не управленческую задачу. Он автоматизирует жизненный цикл сертификатов в границах кластера (ресурсы Certificate, Issuer, Secret), но не формирует корпоративный контур: единых политик выпуска по всей организации, проверки контекста запроса (кто именно запрашивает — не признак вроде владения доменом, а идентичность инициатора), разграничения ролей ИБ и ИТ, сквозного аудита. Смена ЦС требует правки конфигурации Issuer в каждом кластере, централизованного журнала выпущенных сертификатов cert-manager не ведёт, а обращение каждого кластера напрямую к ЦС по ACME расширяет поверхность атаки на критичный компонент PKI. Более того, cert-manager не осуществляет инвентаризацию и мониторинг всех развёрнутых сертификатов за пределами своих же ресурсов — это уже зона ответственности CLM-контура

Ingress и Egress не покрывают весь трафик. Существенная часть коммуникаций идёт мимо них: межсервисный (east-west) трафик внутри кластера, обращения к СУБД, очередям и gRPC-сервисам напрямую из Pod, внешний доступ через Service типов LoadBalancer/NodePort в обход Ingress. Терминация TLS на Ingress без re-encrypt или mTLS до Pod не гарантирует сквозного шифрования до конечного контейнера. При компрометации одного Pod незашифрованный east-west трафик и передаваемые секреты (токены service account, учётные данные СУБД) становятся добычей злоумышленника — со всеми последствиями горизонтального распространения атаки.

Встроенные ЦС Kubernetes, Istio и Vault OSS несут собственные риски в production. Это подтверждают и разработчики: HashiCorp прямо предупреждает, что хранение корневого ЦС внутри Vault OSS (без HSM-интеграции Enterprise) не эквивалентно физической защите ключа («Vault storage is secure, but not as secure as a piece of paper in a bank vault. If your root ЦС is hosted outside of Vault, don’t put it in Vault as well»). В Kubernetes приватный ключ кластерного ЦС лежит на control-plane узлах в открытом виде, доступен всем root-пользователям; для своих внутренних сертификатов встроенный ЦС не предоставляет публичного механизма CRL. У istiod при работе «из коробки» — самоподписанный корень в памяти процесса без HSM-интеграции; сама документация Istio для продуктива рекомендует не использовать этот корень по умолчанию, а строить иерархию с офлайн-корнем («To protect the root ЦС key, you should use a root ЦС which runs on a secure machine offline»). Ни Vault OSS, ни встроенный ЦС Kubernetes, ни istiod не поддерживают HSM/KMS в open-source варианте (в Vault HSM/PKCS#11 — функция Enterprise-редакции), что при компрометации control-plane или istiod означает необходимость перевыпуска всех сертификатов mesh целиком.

Многокластерные сценарии требуют единого пространства доверия. Самоподписанный корень istiod образует изолированный домен доверия на каждый кластер; для федерации между кластерами или доверия внешних систем нужен общий корпоративный корень, который штатно обеспечивают такие интеграции, как plugin-ЦС-cert или istio-csr — но и они закрывают только операционный слой, не добавляя управленческого контура (единых политик, аудита, разграничения ролей).

Итог: для «ванильного» Kubernetes и Istio связка внутреннего/корпоративного ЦС с cert-manager — рабочее и достаточное решение для явно сконфигурированных сценариев Ingress/Egress, но не покрывает Enterprise-уровень управления (единые политики, инвентаризация, сквозной аудит) и не решает задачи защиты east-west трафика без отдельного проектирования mTLS.