TLS для внутренних сервисов (панели администрирования, API, мониторинг, базы за прокси, service-to-service) часто делают «как получится»: где-то ставят self-signed, где-то берут публичный сертификат «чтобы не ругался браузер», а где-то начинают строить private PKI с internal CA. Проблема обычно не в криптографии, а в эксплуатации: кто доверяет, где хранится ключ, как делается ротация, как отзываются сертификаты и как это переживает рост инфраструктуры.
Ниже разберём три подхода — self-signed, internal CA и public CA для внутренних сервисов — именно с позиции админов/DevOps: что будет в проде, какие грабли встречаются и как выбрать вариант, который не превратит TLS в вечный пожар.
Базовая модель: что именно вы «покупаете» TLS-ом
TLS даёт три свойства:
- Шифрование трафика (конфиденциальность).
- Целостность данных (защита от подмены).
- Аутентификация сервиса (клиент понимает, что подключился к правильному узлу).
Во внутренних сетях чаще всего «ломается» именно аутентификация. Шифрование включили — хорошо, но если любой MITM может подсунуть свой сертификат, клиент останется уязвим. А люди быстро привыкают к предупреждениям и жмут «продолжить».
Поэтому ключевой вопрос не «какой сертификат красивее», а как устроено доверие: кто и на каких машинах доверяет какому корню, и как вы этим управляете (то самое trust store management).
Self-signed certificate: быстро, но почти всегда временно
Self-signed — это сертификат, который сам себя подписал: корень и лист в одном лице. Технически канал шифруется. Практически — доверия нет нигде по умолчанию, и вы всё равно должны «доставить доверие» вручную.
Когда self-signed уместен
- Одноразовые стенды, PoC, dev-окружения, где важно не забыть потом заменить.
- Локальные подключения на одну машину, когда вы жёстко закрепляете отпечаток (pinning) и понимаете риск-модель.
- Внутренние технические каналы, где клиент — ваш контролируемый софт, и вы можете встроить доверие к конкретному сертификату.
Типичные проблемы self-signed
- Не масштабируется доверие: на каждый клиент нужно вручную ставить исключение или сертификат.
- Болезненная ротация: новый сертификат означает повторную ручную доставку доверия (или снова «принять риск»).
- Плохой UX: браузеры и клиенты ругаются, и команда привыкает игнорировать предупреждения.
- Ревокация почти отсутствует: даже если вы «отзовёте» сертификат, клиенты чаще всего об этом не узнают, потому что нет CRL/OCSP и процессов.
Self-signed — это не «плохо» криптографически. Это плохо операционно: каждый новый клиент и каждая ротация превращаются в ручной процесс, который не проходит проверку ростом инфраструктуры.
Internal CA и private PKI: лучший контроль, если вы готовы управлять доверием
Internal CA — ваш внутренний центр сертификации. В рамках private PKI вы создаёте корневой (root) и обычно промежуточный (intermediate) CA, а затем выпускаете leaf-сертификаты для сервисов. Клиенты доверяют корню (или промежуточному — по политике), и дальше любой сертификат, выпущенный CA, становится доверенным автоматически.
Плюсы internal CA
- Масштабируемое доверие: один корень в trust store — и сотни сервисов без предупреждений для ваших клиентов.
- Гибкая политика: короткие сроки жизни (30–90 дней), требования к SAN, ограничения по KeyUsage и ExtendedKeyUsage.
- mTLS становится реальным: можно выдавать клиентские сертификаты сервисам и людям, строить service identity.
- Автоматизация: ACME внутри компании, интеграция с Kubernetes, service mesh, CI.
Минусы internal CA (о чём часто забывают)
- Trust store management: нужно поддерживать доставку корневого сертификата на рабочие станции, серверы, контейнеры, мобильные устройства.
- Компрометация CA-ключа: утечка ключа CA — событие уровня «меняем доверие везде».
- Ревокация сложнее, чем кажется: CRL/OCSP требуют инфраструктуры и дисциплины, а часть клиентов проверяет статус «по желанию» или не проверяет вовсе.
- Точка ответственности: если CA или процесс выпуска недоступен, релизы и автопродление сертификатов встанут.
Если внутренние сервисы живут на отдельных узлах, часто удобнее держать PKI-автоматизацию и контроллеры в предсказуемом окружении (выделенный сервер, отдельный сегмент, отдельные политики доступа). В таких сценариях обычно проще организовать всё на VDS, чем «размазать» ответственность по рабочим машинам и случайным контейнерам.
Практический фундамент: заведите единый реестр, кто владелец сервиса и где лежат ключи, а дальше постепенно автоматизируйте выпуск и ротацию. Отдельно полезно иметь мониторинг истечения сроков и регламент аварийной замены ключей. По этой теме пригодится материал про алерты по окончанию TLS-сертификатов и безопасное продление.
Практическая схема: root offline + intermediate online
Самый рабочий паттерн для большинства компаний:
- Root CA создаётся один раз и хранится офлайн (в идеале аппаратно, минимум — на изолированном носителе).
- Intermediate CA работает онлайн и подписывает сертификаты сервисов.
- Если intermediate скомпрометирован, вы перевыпускаете intermediate, не меняя root во всех trust store (или меняя его существенно реже и планово).
Где именно хранится доверие: нюансы, которые бьют по рукам
«Добавить корень в доверенные» звучит просто, пока не выясняется, что trust store — не один:
- ОС (Debian/Ubuntu, RHEL-подобные, Windows, macOS).
- Java со своим keystore.
- Go обычно опирается на системное хранилище, но контейнеры могут быть «голые».
- Python/cURL/OpenSSL могут использовать разные пути к CA bundle в разных окружениях.
- Браузеры и корпоративные политики (особенно Windows через GPO или MDM).
- Контейнеры: образ может не содержать актуальные CA, а обновление образов — отдельный процесс.
Именно поэтому trust store management — ключевой критерий: сможете ли вы гарантированно и быстро обновлять доверие везде, где живут клиенты.
Ротация и сроки жизни: внутренний PKI выигрывает дисциплиной
Частая ошибка — выпускать внутренние сертификаты на 2–5 лет «чтобы не трогать». Это откладывает боль, но повышает риск: если ключ утёк, злоумышленник сможет им пользоваться долго. На практике проще сделать наоборот:
- Root CA — долгий срок (например, 10–20 лет), но офлайн.
- Intermediate CA — средний срок (например, 3–5 лет).
- Leaf-сертификаты — короткий срок (например, 30–90 дней) и автоматическое обновление.
Тогда даже без идеальной ревокации ущерб от утечки отдельного ключа ограничен временем жизни leaf-сертификата.
Минимальный «скелет» процедур для internal CA
Чтобы internal CA не стал хрупкой игрушкой, зафиксируйте хотя бы базовые практики:
- Инвентарь: какие сервисы, какие FQDN, где ключ, кто владелец, когда истекает.
- Регламент ротации: кто и как меняет сертификат, как откатываемся, как тестируем перед релизом.
- Политика ключей: отдельный ключ на сервис, запрет на шаринг приватного ключа между узлами без необходимости.
- Аварийный сценарий: что делаем при утечке leaf-ключа, intermediate-ключа, root-ключа.
Public CA for internal: «чтобы доверяли все», но с ограничениями
Public CA for internal — выпуск сертификата у публичного УЦ для имени внутреннего сервиса. Плюс очевиден: доверие уже есть «везде» (браузеры, ОС, устройства). Минусы — в деталях: публичные УЦ живут по правилам индустрии, и эти правила часто не дружат с «внутренними именами».
Что реально можно и нельзя с публичным CA
- Нельзя выпускать сертификаты на имена без контроля в публичном DNS и на внутренние зоны вроде
.local. Нужен домен, которым вы реально управляете, и валидация (обычно DNS-01 или HTTP-01). - Можно выпускать сертификаты на внутренние сервисы, если их имена находятся в вашем домене (например,
svc.example.com), даже если сами IP недоступны извне. - Нужно соблюдать сроки жизни и требования экосистемы браузеров, а также иметь процессы продления.
Плюсы public CA for internal
- Почти нулевой trust store management: корни уже есть у большинства клиентов.
- Удобно для смешанных сред: подрядчики, BYOD, мобильные устройства, гостевые ноутбуки.
- Меньше «самописной PKI»: часть ответственности за совместимость цепочек и базовые требования берёт на себя УЦ.
Минусы public CA for internal
- Зависимость от внешнего процесса: правила валидации, ограничения по rate limit, изменения требований.
- DNS становится критичным: автоматизация обычно завязана на DNS-01 или на доступность HTTP-01, а это требует дисциплины, прав доступа и аудита.
- Нельзя выпускать «всё подряд»: внутренние схемы именования и нестандартные сценарии упираются в политику публичного CA.
- Риск раскрытия метаданных: сам факт существования FQDN может быть заметен в процессах валидации и публичной экосистеме сертификатов (не всегда критично, но иногда важно).
Если ваш кейс ближе к «нужно, чтобы открывалось без предупреждений на любых устройствах», то проще идти в публичные цепочки доверия и покупать/выпускать сертификаты у доверенного УЦ. Для админки, портала для партнёров и смешанных клиентов это часто снижает операционные затраты на доверие. При необходимости можно подобрать подходящие SSL-сертификаты под ваш домен и сценарий валидации.
Как выбрать: практическая матрица решений
Обычно выбор упирается в два вопроса: кто ваши клиенты и можете ли вы управлять доверием (trust store) централизованно.
Если сервис строго внутренний и клиенты под вашим контролем
Выбирайте internal CA и стройте private PKI. Это лучший баланс масштабируемости и безопасности. Да, придётся сделать trust store management, но это инвестиция, которая окупается на 10+ сервисах и при появлении mTLS, сегментации и zero trust-подходов.
Если сервисом пользуются «чужие» устройства и смешанные клиенты
Рассмотрите public CA, если вы можете дать сервисам корректные FQDN в вашем домене и готовы автоматизировать выпуск и продление. Это снижает трение для пользователей, партнёров и подрядчиков.
Если это временно, локально или одна интеграция
Self-signed допустим, но закладывайте план выхода: кто заменит, когда, и как вы не забудете. Желательно сразу ставить короткий срок и фиксировать fingerprint в конфиге клиента, а не «доверять всему подряд».
Частые ошибки и как их избежать
Ошибка 1: один self-signed на всю инфраструктуру
Иногда берут один сертификат и ставят на 20 сервисов. Это превращает один компрометированный ключ в компрометацию всего. Правило простое: отдельный ключ на сервис (и лучше автоматизированная выдача).
Ошибка 2: internal CA без процесса доставки корня
Запустить CA легко, а вот обеспечить доверие на рабочих местах, в контейнерах, в Java-приложениях и на CI-раннерах — нет. Планируйте trust store management как отдельный проект: инвентаризация клиентов, каналы доставки, контроль версии корневого сертификата, аудит изменений.
Ошибка 3: отсутствие инвентаря сертификатов
Не важно, public CA или internal CA: если вы не знаете, где какие сертификаты и когда истекают, вы получите массовый даунтайм «в самый неподходящий день». Минимум, который стоит внедрить:
- реестр сертификатов (хост, имя, срок, владелец, где хранится ключ);
- алерты по истечению сроков;
- регламент ротации и тестирование обновления.
Ошибка 4: игнорирование SAN и современных клиентов
Современные клиенты проверяют имя в SAN, а CN считают устаревшим. Для внутренних сервисов это особенно важно: если вы добавили DNS-алиас или переименовали сервис, сертификат должен это отражать.
Минимальные операционные рекомендации (без привязки к продуктам)
Если резюмировать в «чек-лист здравого смысла»:
- Для внутреннего PKI используйте модель root offline + intermediate online.
- Делайте короткоживущие leaf-сертификаты и автоматическую ротацию.
- Разделяйте сертификаты по сервисам, не переиспользуйте один ключ везде.
- Продумайте trust store management: ОС, контейнеры, языковые рантаймы, CI, устройства.
- Если не уверены, что клиенты проверяют CRL или OCSP, компенсируйте это короткими сроками жизни и быстрым перевыпуском.
- Для public CA используйте нормальные FQDN в вашем домене и отлаженную автоматизацию подтверждения владения.
Итог: лучший вариант зависит от клиентов и управления доверием
Если у вас 1–2 сервиса и всё живёт на одной машине, self-signed может быть приемлемым компромиссом. Как только сервисов становится больше, появляются команды, окружения, контейнеры и mTLS, internal CA и private PKI обычно дают наилучший контроль и предсказуемость. А если вашим внутренним сервисом пользуются внешние устройства и вы хотите «работает везде без плясок», тогда public CA становится прагматичным выбором, но только при корректной доменной модели и автоматизации.
Ключевой критерий во всех трёх вариантах — не «сертификат», а процессы: выпуск, хранение ключей, ротация и trust store management. Если процессы выстроены, TLS перестаёт быть головной болью и становится базовой инфраструктурной гигиеной.
