PKI: Vault как центр сертификации

Как заменить ручной выпуск TLS-сертификатов на автоматическую выдачу коротких сертификатов по запросу.

PKI engine — движок, превращающий Vault в центр сертификации (CA): он выпускает TLS-сертификаты по запросу с коротким сроком жизни и сам управляет их жизненным циклом.

Традиционный выпуск сертификатов мучителен: ручные CSR, годовые сроки, забытые продления, упавший в проде HTTPS. PKI-движок автоматизирует это: сервис запрашивает сертификат при старте, получает его на часы/дни и обновляет автоматически.

Настройка CA

Сначала движок становится корневым (или промежуточным) CA:

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki

# корневой сертификат CA
vault write pki/root/generate/internal \
  common_name="internal-ca" \
  ttl=87600h

Роль с ограничениями

Роль задаёт, для каких доменов и на какой срок можно выпускать сертификаты:

vault write pki/roles/internal-web \
  allowed_domains="internal" \
  allow_subdomains=true \
  max_ttl=72h

Эта роль выпустит сертификат для api.internal или db.internal, но не для example.com — домены жёстко ограничены.

Выпуск сертификата

vault write pki/issue/internal-web \
  common_name="api.internal" \
  ttl=24h
{
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\n...",
    "private_key": "-----BEGIN RSA PRIVATE KEY-----\n...",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\n...",
    "serial_number": "3a:1f:..."
  }
}

За один вызов сервис получает готовый сертификат, приватный ключ и цепочку CA. Никаких ручных CSR.

Почему короткие сертификаты лучше

Парадоксально, но короткий срок безопаснее. Сертификат на сутки делает почти ненужными списки отзыва (CRL): скомпрометированный сертификат и так протухнет завтра. Короткие сроки заставляют автоматизировать обновление, что убирает человеческий фактор «забыли продлить». Это идеология современного mTLS между сервисами.

Как работает под капотом

При issue Vault генерирует пару ключей (или принимает CSR через sign), формирует сертификат, подписывает его приватным ключом CA внутри барьера и возвращает результат. Приватный ключ CA не покидает Vault. Каждый выпуск регистрируется, что даёт полный аудит выданных сертификатов. Для совместимости со старыми системами PKI ведёт CRL, но при коротких TTL опора на него минимальна.

Частые ошибки

  • Корневой CA прямо в проде с длинным TTL — лучше промежуточный CA, подписанный офлайн-корнем.
  • Роль без allowed_domains — выпуск сертификата на любой домен, риск подмены.
  • Долгие TTL сертификатов — возвращают проблему отзыва и ручных продлений.
  • Не автоматизировать обновление — короткие сертификаты протухнут и уронят сервис.

Итог

  • PKI-движок делает Vault центром сертификации с автоматическим выпуском TLS.
  • Роли ограничивают домены и сроки; issue сразу отдаёт сертификат, ключ и цепочку.
  • Короткие сроки безопаснее: меньше зависимость от CRL, обязательная автоматизация продления.
Проверьте себя
1. Что PKI engine позволяет Vault?
AХранить пароли
BВыступать центром сертификации и выпускать TLS-сертификаты по запросу
CШифровать данные как сервис
DЛогиниться приложениям
2. Почему короткоживущие сертификаты считаются безопаснее?
AОни меньше по размеру
BСкомпрометированный сертификат быстро протухает, снижая зависимость от списков отзыва
CОни не требуют приватного ключа
DИх нельзя отозвать
3. Зачем в роли PKI задают allowed_domains?
AДля ускорения выпуска
BЧтобы ограничить, на какие домены можно выпускать сертификаты, и не допустить подмену
CЭто поле для срока действия
DЧтобы включить CRL