step-ca на Ubuntu 24.04: пошаговая установка

MAATRIX

Рано или поздно во внутренней сети накапливается десяток сервисов, которым нужен TLS: панель мониторинга, приватный API, dashboard для команды, mTLS между микросервисами. Тащить их все под публичный домен и Let's Encrypt неудобно и местами небезопасно — это внутренний трафик, ему не место в публичном Certificate Transparency логе. Решение — собственный центр сертификации, который выпускает короткоживущие сертификаты и сам их продлевает. step-ca от Smallstep делает это без танцев с OpenSSL и ручным ведением реестра сертификатов.

Что такое step-ca и зачем он нужен

step-ca — это ACME-совместимый центр сертификации с открытым исходным кодом, который можно поднять на своём сервере за 20 минут. В отличие от ручной генерации сертификатов через openssl req он берёт на себя всё, что обычно делают руками и забывают: ведение серийных номеров, CRL, безопасное хранение приватного ключа CA, выдачу по протоколу ACME (тому же, что использует Let's Encrypt) и — самое важное — короткий срок жизни сертификатов с автоматическим продлением.

Типичные сценарии применения:

• mTLS между внутренними сервисами — каждый под получает свой сертификат, соседние сервисы проверяют друг друга по нему, а не по паролю или общему токену.
• TLS для internal-only панелей (Grafana, Vault, внутренние API), куда не хочется выпускать публичный сертификат.
• Единая точка доверия для нескольких серверов — один root CA, сертификаты которого признают все машины в инфраструктуре.
• Автоматическая ротация без человека — сертификаты живут часы или дни, а не год, что резко снижает ущерб от утечки ключа.

Ключевая идея step-ca — короткий TTL (по умолчанию 24 часа для leaf-сертификатов) плюс демон-агент, который тихо продлевает их в фоне. Если сертификат скомпрометирован, он и так истечёт в течение суток — не нужно гоняться за отзывом по всей инфраструктуре.

Подготовка сервера

Понадобится чистый сервер на Ubuntu 24.04 с 1 vCPU и 1 ГБ RAM — step-ca лёгкий, база на BadgerDB не требовательна к ресурсам даже при сотнях выданных сертификатов в день. Для CA важнее стабильность и приватность сети, чем мощность, поэтому подойдёт минимальный тариф VPS в приватном сегменте, недоступном напрямую из интернета.

Перед установкой:

sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname ca.internal.example

Определитесь с DNS-именем CA заранее — оно зашивается в root-сертификат при инициализации, и поменять его потом без переинициализации CA нельзя. Если сервер живёт только во внутренней сети, добавьте A-запись в приватный DNS или пропишите имя в /etc/hosts на всех клиентах, которые будут получать сертификаты.

Откройте порт, на котором будет слушать step-ca (по умолчанию 443, но для internal CA часто используют отдельный, например 8443, чтобы не конфликтовать с прочими сервисами на той же машине):

sudo ufw allow 8443/tcp
sudo ufw status

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

Установка step-ca и step CLI

Smallstep публикует официальные .deb-пакеты для step-ca (сам сервер) и step CLI (клиентская утилита для инициализации и получения сертификатов). Оба нужны — CLI используется даже на самом сервере CA для настройки.

# step CLI
curl -fsSL https://dl.smallstep.com/gh-release/cli/docs-cli-install/latest/step-cli_amd64.deb -o step-cli.deb
sudo dpkg -i step-cli.deb

# step-ca (сервер)
curl -fsSL https://dl.smallstep.com/gh-release/certificates/docs-ca-install/latest/step-ca_amd64.deb -o step-ca.deb
sudo dpkg -i step-ca.deb

Проверьте, что бинарники встали:

step version
step-ca version

На момент написания (конец августа 2026) в репозитории Smallstep актуальны версии step CLI и step-ca в районе 0.28–0.29, но точную цифру смотрите в выводе step version — проект обновляется активно, и жёстко привязываться к номеру версии в статье смысла нет.

Пакет создаёт системного пользователя step, от имени которого будет работать демон, и каталог /etc/step-ca для конфигурации.

Инициализация центра сертификации

Это самый важный шаг — здесь генерируется root-ключ, и его компрометация означает компрометацию доверия ко всей инфраструктуре. Инициализация выполняется от имени пользователя step (или через sudo -u step), чтобы файлы сразу принадлежали правильному владельцу:

sudo -u step step ca init \
  --name "Internal CA" \
  --dns "ca.internal.example" \
  --address ":8443" \
  --provisioner "admin@internal.example" \
  --deployment-type standalone

Мастер спросит:

• пароль для root-ключа — используйте генератор паролей, а не что-то запоминаемое; этот пароль защищает офлайн-ключ, который трогаете только при ротации root CA;
• пароль для intermediate-ключа — им подписывается каждый выданный сертификат, он должен быть доступен демону step-ca в рантайме.

По умолчанию step-ca создаёт двухуровневую иерархию: root CA (офлайн после инициализации, используется только для подписи intermediate) и intermediate CA (онлайн, подписывает leaf-сертификаты). Это стандартная практика PKI — если intermediate когда-нибудь скомпрометирован, вы отзываете только его, не трогая root, которому доверяют все клиенты.

Результат инициализации — каталог /etc/step-ca со структурой:

/etc/step-ca/
├── certs/
│   ├── root_ca.crt
│   └── intermediate_ca.crt
├── secrets/
│   ├── root_ca_key
│   └── intermediate_ca_key
├── config/
│   ├── ca.json
│   └── defaults.json
└── db/

Файл root_ca.crt — это тот сертификат, который нужно будет разложить по клиентским машинам, чтобы они доверяли выданным CA сертификатам.

systemd, автозапуск и защита ключа

Пароль от intermediate-ключа демону step-ca нужен при каждом старте, а хранить его в открытом виде в юните systemd — плохая идея. Сохраните пароль в отдельный файл с жёсткими правами:

echo 'ваш-пароль-intermediate' | sudo tee /etc/step-ca/password.txt
sudo chown step:step /etc/step-ca/password.txt
sudo chmod 600 /etc/step-ca/password.txt

Пакет step-ca уже ставит юнит step-ca.service, но его нужно донастроить на использование файла с паролем. Отредактируйте /etc/systemd/system/step-ca.service (или переопределите через systemctl edit step-ca):

[Service]
Type=simple
User=step
Group=step
Environment=STEPPATH=/etc/step-ca
ExecStart=/usr/bin/step-ca /etc/step-ca/config/ca.json --password-file /etc/step-ca/password.txt
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Включите и запустите:

sudo systemctl daemon-reload
sudo systemctl enable --now step-ca
sudo systemctl status step-ca

Проверка, что CA действительно отвечает:

curl -s https://ca.internal.example:8443/health

Ожидаемый ответ — {"status":"ok"}. Если curl ругается на самоподписанный сертификат, это нормально: добавьте --cacert /etc/step-ca/certs/root_ca.crt к тестовому запросу либо доверьте root-сертификат системе (см. следующую секцию).

Выпуск сертификатов и автоматическая ротация

На клиентской машине, которой нужен сертификат, сначала нужно объяснить ей, кому доверять:

step ca bootstrap \
  --ca-url https://ca.internal.example:8443 \
  --fingerprint <отпечаток-root-сертификата>

Отпечаток печатается при инициализации CA (step ca init выводит его в конце) или получается командой step certificate fingerprint /etc/step-ca/certs/root_ca.crt на сервере CA. Bootstrap кладёт root-сертификат в локальное хранилище доверия step на клиенте — с этого момента step ca на клиенте знает, кому доверять.

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

step ca certificate "app.internal.example" app.crt app.key

Но ручной выпуск — это то, чего step-ca как раз позволяет избежать. Для автоматической ротации есть встроенный демон step-ca renew через systemd-таймер или процесс-обёртку step ca renew в режиме daemon:

sudo step ca certificate "app.internal.example" \
  /etc/ssl/app.crt /etc/ssl/app.key \
  --provisioner "admin@internal.example"

sudo step ca renew --daemon \
  /etc/ssl/app.crt /etc/ssl/app.key \
  --exec "systemctl reload nginx"

Флаг --daemon запускает процесс, который следит за сроком действия сертификата и продлевает его примерно на трети оставшегося TTL, автоматически выполняя --exec после успешного продления — удобно, чтобы nginx или другой сервис подхватил новый сертификат без ручного вмешательства. Для продакшна такой процесс стоит обернуть в собственный systemd-юнит с Restart=always.

Если сервисы говорят по ACME (умеют сами получать сертификаты, как nginx с certbot), step-ca можно настроить как ACME-провайдер и получать сертификаты стандартными ACME-клиентами, направленными на https://ca.internal.example:8443/acme/acme/directory — тогда логика продления вообще не ваша забота, её берёт на себя ACME-клиент. Тем, кто уже сравнивал certbot и acme.sh для публичных доменов, схема покажется знакомой — разница только в том, что directory URL смотрит на ваш CA, а не на Let's Encrypt.

Для мониторинга самого CA (доступность, число выданных сертификатов, ошибки выдачи) удобно поднять рядом Prometheus и Grafana — step-ca экспортирует метрики в формате Prometheus на отдельном порту, если включить это в ca.json.

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