Свой внутренний УЦ для корпоративной сети: когда он дешевле покупных сертификатов

MAATRIX

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

Когда свой УЦ дешевле покупки сертификатов

Один купленный сертификат на публичный сайт почти всегда проще и дешевле, чем возня со своим CA — Let's Encrypt закрывает эту задачу бесплатно и автоматически, а для платных wildcard- или EV-сертификатов коммерческий УЦ понятнее, потому что за ним стоит готовая цепочка доверия во всех браузерах и ОС из коробки. Свой внутренний CA имеет смысл считать не как замену этому, а как отдельное решение для другой задачи — TLS и mTLS между внутренними сервисами, которые никогда не смотрят наружу.

Экономика начинает работать в вашу пользу, когда совпадают несколько условий:

• Внутренних сервисов больше десятка. Админки Grafana, Portainer, внутренние API между микросервисами, dev/stage-окружения, приватный Docker registry — если под каждый нужен отдельный сертификат, а домены не резолвятся из публичного DNS, коммерческий УЦ с оплатой за сертификат или за домен в год превращается в постоянную статью расходов.
• Серверов и виртуалок много, и они плодятся. Каждая новая VM под тестовое окружение — это либо ещё один платный сертификат, либо ещё один самоподписанный костыль. Свой CA с автоматической выдачей через ACME убирает ручной шаг из цикла независимо от того, сколько серверов появится за квартал.
• Сотрудники работают с управляемых устройств. Корпоративные ноутбуки под MDM или групповыми политиками, где корневой сертификат можно раздать централизованно одной командой, а не просить каждого руками кликать «установить сертификат». Без управляемого парка распространение корня становится отдельным проектом — и это может перевесить экономию.
• Нужен mTLS между сервисами. Взаимная аутентификация сервис-сервис — по определению внутренняя PKI-задача, публичные CA её не решают, и свой CA здесь не альтернатива, а по сути единственный практичный вариант.

Если у вас три внутренних сервиса и десять сотрудников на личных ноутбуках без MDM — не стройте свой CA, разница в трудозатратах не окупится. Если сервисов за тридцать, серверы поднимаются и гасятся регулярно, а парк устройств управляемый — считать пора всерьёз.

Архитектура: зачем нужны отдельно root и intermediate

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

• Root CA (корневой) — самый долгоживущий и самый ценный ключ во всей схеме. Он подписывает только intermediate-сертификат, один раз, и после этого в идеале не участвует в повседневной работе вообще. Именно root-сертификат (не ключ) распространяется на клиентские устройства и попадает в системные хранилища доверия.
• Intermediate CA (промежуточный) — сертификат, подписанный root'ом, который и занимается ежедневной выдачей сертификатов для сервисов. Именно он работает на сервере CA, доступном по сети, и именно его компрометация — реалистичный риск, с которым нужно уметь жить.

Смысл разделения простой: если скомпрометирован intermediate-ключ (сервер CA взломали, ключ утёк), вы отзываете и перевыпускаете только его, не трогая корень и не заставляя всех сотрудников заново устанавливать новый root-сертификат на все устройства. Если бы CA работал через один плоский root-ключ, любая его компрометация означала бы полный обход всей инфраструктуры доверия и повторное распространение нового корня на каждую машину — куда более дорогая операция, чем перевыпуск intermediate.

Root-ключ после инициализации разумно держать офлайн — на отдельном зашифрованном носителе, не на том же сервере, где крутится сама служба выдачи. Это неудобно ровно один раз в жизни CA (при инициализации и очень редких переподписаниях intermediate), зато снимает с сервера CA статус «всё пропало при любом взломе».

Разворачиваем корневой и промежуточный сертификат

Практическая реализация — отдельный небольшой сервер под сам CA, без публичного доступа снаружи. Из открытых инструментов для этой задачи чаще всего берут step-ca от Smallstep — он говорит по протоколу ACME (том же, что использует Let's Encrypt), но выдаёт сертификаты на внутренние домены, IP и в любых масштабах, недоступных публичному CA. Мы подробно разбирали установку в статье как установить и настроить step-ca на VPS — здесь пройдёмся по сути шагов именно в контексте экономики.

Инициализация сразу создаёт двухуровневую иерархию — root и intermediate одной командой:

sudo step ca init \
  --name "Internal Corp CA" \
  --dns "ca.internal.example.com" \
  --address ":8443" \
  --provisioner "admin@example.com"

На выходе — структура каталогов с двумя парами ключ/сертификат:

/etc/step-ca/
├── certs/
│   ├── root_ca.crt         # раздаётся на все клиентские устройства
│   └── intermediate_ca.crt # работает на сервере CA
├── secrets/
│   ├── root_ca_key         # уносим в офлайн-хранилище
│   └── intermediate_ca_key # остаётся на сервере CA
└── config/ca.json

Дальше сервис поднимается как systemd-служба, слушает порт только из внутренней сети (файрвол на VPC или ufw-правило по подсети), и после этого CA готов выдавать сертификаты через ACME-провижнер:

step ca provisioner add acme --type ACME
sudo systemctl restart step-ca

С этого момента любой ACME-совместимый клиент — certbot, acme.sh, встроенный ACME в Caddy или Traefik — может получить сертификат у вашего CA, указав в качестве сервера не acme-v02.api.letsencrypt.org, а адрес вашего внутреннего CA. Разница с покупкой сертификата у коммерческого УЦ здесь принципиальная: выпуск больше не стоит денег и не требует ручного шага «зайти в личный кабинет, выбрать домен, оплатить, скачать файл» на каждый новый сервис.

Автоматизация выпуска для внутренних сервисов

Ручной выпуск сертификата вручную решает задачу один раз, но экономика собственного CA раскрывается только при автоматической выдаче и продлении — иначе вы просто заменили счёт от коммерческого УЦ на ручной труд инженера, а это тоже не бесплатно.

Для отдельных сервисов на VM удобен демон-режим step-cli, который сам следит за сроком годности и продлевает сертификат заранее:

step ca renew --daemon \
  service1.crt service1.key \
  --exec "systemctl reload nginx"

Для инфраструктуры на Kubernetes стандартный путь — cert-manager с ClusterIssuer, настроенным на ваш внутренний CA как ACME-эндпоинт: тогда сертификаты для Ingress-ресурсов выпускаются и продлеваются автоматически по мере появления новых сервисов, без ручного вмешательства при каждом деплое. Мы отдельно разбирали похожую схему автопродления для IKEv2 в статье cert-manager: автопродление сертификатов IKEv2 — тот же принцип переносится и на HTTP-сервисы за Ingress.

Ключевой параметр экономики — короткий срок жизни сертификата. У step-ca по умолчанию это 24 часа, и это осознанный выбор, а не ограничение: если сертификат живёт сутки, автоматическое продление обязано работать, но и цена компрометации ключа резко падает — украденный сертификат бесполезен уже через несколько часов, что снимает часть требований к дорогой инфраструктуре отзыва (CRL, OCSP), которую иначе пришлось бы строить отдельно.

Распространение корневого сертификата на устройства

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

Практические пути:

• Групповые политики (GPO) для Windows-парка — корневой сертификат раскладывается через политику домена на все машины при следующем обновлении групповых политик, без участия пользователя.
• MDM-профиль для macOS/iOS/Android — тот же принцип, но через профиль конфигурации, который push'ится централизованно на корпоративные устройства.
• Ansible-плейбук для Linux-серверов — задача update-ca-certificates (Debian/Ubuntu) или update-ca-trust (RHEL-семейство), прогоняемая по инвентарю при каждом изменении корня.
• Образ для CI-раннеров — если сборки обращаются к внутреннему Docker registry или API за сертификатом от вашего CA, корень нужно вшить в базовый образ раннера, иначе сборки начнут падать на проверке цепочки сертификата.

sudo cp root_ca.crt /usr/local/share/ca-certificates/internal-ca.crt
sudo update-ca-certificates

Если в компании нет единой системы управления устройствами — MDM, домена Windows или хотя бы централизованного Ansible-инвентаря по Linux-машинам, — эта часть задачи ложится на ручной обход парка техники. Для десятка управляемых ноутбуков это разовая работа на час. Для полусотни разнородных личных устройств это уже непрерывная головная боль, которая может съесть всю экономию на сертификатах — именно поэтому пункт «сотрудники под управляемыми устройствами» из первого раздела не формальность, а реальный порог целесообразности.

Отдельно стоит вопрос сторонних интеграций: вебхуки от внешних SaaS-сервисов, партнёрские API, мобильные приложения не под вашим MDM — все они физически не могут довериться самодельному корню, потому что не используют ваше корпоративное хранилище сертификатов. Для таких точек по-прежнему нужен сертификат от публично доверенного CA.

Риски и издержки: за что вы отвечаете взамен экономии

Собственный CA — это не только экономия, но и новая ответственность, которую раньше нёс коммерческий УЦ. Стоит честно проговорить, что именно переходит на вашу сторону.

Компрометация root-ключа. Если приватный ключ корня утекает — из репозитория, с уволенного ноутбука администратора, из бэкапа без шифрования — у вас нет автоматического способа его отозвать так, как это делает публичный CA через глобальный CRL. Практический план на этот случай: root-ключ офлайн с самого начала, доступ к нему у ограниченного числа людей, регламент «что делаем при компрометации» прописан заранее, а не придумывается в момент инцидента.

Забытый факт существования CA. Отдельный и недооценённый риск — не компрометация, а обратная ситуация: про сам CA просто забывают на годы, срок действия корня истекает, и всё, что на нём держится, останавливается разом. Разбор похожего инцидента — в статье внутренний CA протух через десять лет и остановил обмен между сервисами: там дело было не во взломе, а в том, что мониторинг самого корневого сертификата никто не настроил, ведь «сертификаты сервисов же продлеваются сами». Мониторинг нужен на оба уровня — и на сертификаты сервисов, и отдельно на срок действия root и intermediate, коротко об этом подходе в статье мониторинг сертификатов и доменов.

Точка единого отказа. Если сервер CA недоступен, уже выданные сертификаты продолжают работать до истечения срока, но новые выпустить и продлить существующие нельзя — при коротком сроке жизни (те же 24 часа) простой CA больше суток начинает рвать TLS-соединения по всей внутренней инфраструктуре. Отсюда требования: отдельный сервер под CA, бэкап каталога с секретами, проверенный план восстановления.

Аудит и комплаенс. Если компания проходит внешний аудит безопасности или работает по требованиям, которые ссылаются на сертификаты «доверенного CA», собственный CA нужно будет объяснять аудитору отдельно — он не входит автоматически в списки доверенных корней. Это не блокер, но лишний пункт документации, которого не было бы при покупке сертификатов у известного коммерческого УЦ.

Ни один из этих рисков не перечёркивает экономику из первого раздела — но каждый имеет цену в человеко-часах и должен быть заложен в расчёт заранее, а не всплыть постфактум.

Сравнение: свой CA против покупных сертификатов

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

Частые вопросы