Привет! 👋 Продолжаем тему PKI. В прошлый раз разобрались, что такое leaf, intermediate и root сертификаты. Сегодня поговорим про несколько веток доверия и почему это иногда превращается в настоящую боль для инфраструктуры. ❓ Почему в одной инфраструктуре бывает несколько веток сертификатов Иногда внутри одного контура существует несколько PKI-иерархий Ветка 1 Devopsintapki Test Root CA ➡️ Devopsintapki Test TLS CA ➡️ nginx Ветка 2 Devopsintapki Test Environment Root CA ➡️ Devopsintapki Test Environment Issuing CA 1 ➡️ tyk И это две разные PKI-иерархии Компании часто делают 🔵 отдельный Root для TEST 🔵 отдельный Root для PROD 🔵 отдельный Root для DEV 🔵 иногда дополнительные промежуточные CA Формально это нормальная практика. Но иногда на практике 〰️ это превращается в настоящую инфраструктурную боль. Почему❓ Каждая такая ветка 〰️ отдельная зона доверия Клиент доверяет только тем серверам, чья цепочка сертификатов ведёт к знакомому Root CA Если цепочка ведёт к другому Root 〰️ соединение просто не установится. ⚠️ Чем опасны разные ветки доверия Допустим серверный сертификат подписан цепочкой к Devopsintapki Test Environment Root CA А в truststore лежит Devopsintapki Test Root CA Для Java и большинства TLS-клиентов это две разные вселенные Даже если названия похожи. Результат будет примерно такой PKIX path building failed # а ещё завёрнутый в TLS handshake error unable to find valid certification path TLS handshake error То есть TLS не сможет построить цепочку доверия ⚠️ Что ещё хуже Иногда в truststore складывают все корни подряд 🔵 тестовые 🔵 продовые 🔵 временные 🔵 старые Это может привести к 🔵 неожиданному доверию к тестовой инфраструктуре в проде 🔵 подключению к не тому серверу 🔵 нарушению сегментации окружений Особенно критично это в 🔵 банковских системах 🔵 API-шлюзах 🔵 инфраструктуре с mTLS ✅ Как делают в более зрелых PKI Не всегда нужно плодить отдельный Root CA для каждого окружения. Часто используют более управляемую архитектуру ROOT CA (офлайн) ⬇️ DEV Issuing CA TEST Issuing CA PREPROD Issuing CA PROD Issuing CA То есть 🔵 Root один 🔵 он хранится оффлайн 🔵 сегментация делается через разные issuing CA Это сильно упрощает 🔵 управление доверенными сертификатами 🔵 обновление инфраструктуры 🔵 автоматизацию выпуска сертификатов При этом безопасность сохраняется. ✅ В зрелых инфраструктурах бывает ещё интереснее Иногда issuing CA делают даже по типу нагрузки внутри одного окружения. Например PROD Root ⬇️ Web Issuing CA mTLS Issuing CA Kubernetes Issuing CA Internal Services CA Это позволяет 🔵 изолировать разные типы сервисов 🔵 быстрее отзывать скомпрометированные сертификаты 🔵 ограничивать область действия сертификатов ✅ Когда PKI перестаёт быть болью Если всё делается вручную 〰️ это действительно превращается в боль. Но при нормальной автоматизации поддержка нескольких веток становится вполне управляемой. Обычно используют для автоматизации 🔵 HashiCorp Vault PKI 🔵 Smallstep CA 🔵 EJBCA 🔵 cert-manager в Kubernetes В этом случае 🔵 выпуск сертификатов автоматический 🔵 ротация не требует ручной работы 🔵 отзыв сертификатов происходит централизованно ✅ Главное правило TEST доверяет только TEST PROD доверяет только PROD Root-сертификаты разных веток 〰️ это разные зоны доверия PKI 〰️ это не просто сертификаты. Это границы безопасности. #tls #ssl #java #pki #pkix #security #devops