Работа с сертификатами в проекте Netgap
Эта методичка описывает все аспекты работы с X.509-сертификатами в проекте Netgap: от теории (что такое сертификат, ключи, цепочка доверия) до практики — развертывание собственной PKI для тестовых стендов, выпуск и инспекция сертификатов через OpenSSL, настройка mTLS на rustls, извлечение идентичности клиента (CN и SPIFFE ID), отзыв и автоматическая ротация.
Сертификаты в Netgap — не вспомогательная деталь, а часть модели безопасности продукта:
- весь трафик между шлюзами шифруется TLS 1.3;
- компоненты и сервисы аутентифицируют друг друга взаимно — по mTLS: сертификат обязан предъявить не только сервер, но и клиент;
- источник сертификатов не ограничивается: заказчик вправе использовать сертификаты любого удостоверяющего центра — публичного CA или собственного корпоративного УЦ, если таковой имеется;
- TLS-стек Netgap — библиотека
rustls, которая по умолчанию отвергает слабые ключи и устаревшие практики, поэтому сертификаты должны быть выпущены правильно с первого раза.
Часть статей методички показывает, как развернуть собственную (private) PKI и выпускать сертификаты через OpenSSL. Эта инфраструктура нужна для целей тестирования, экспериментов и локальных стендов разработки — чтобы быстро получить полный комплект файлов (ca.crt, серверные и клиентские сертификаты) без обращения к внешнему УЦ. В производственной среде выбор удостоверяющего центра остается за заказчиком.
Структура методички
Статьи расположены в порядке, в котором тему удобно осваивать: сначала теория, затем выпуск сертификатов руками, их проверка, использование в коде и, наконец, эксплуатация (отзыв и автоматизация).
| Шаг | Статья | Что закрывает |
|---|---|---|
| 1 | Эта страница | Теория: что такое сертификат X.509, из чего он состоит, форматы файлов, жизненный цикл |
| 2 | Ключи и алгоритмы | Пара приватный/публичный ключ, RSA vs ECDSA vs Ed25519, что выбирать для CA и сервисов, правила обращения с приватным ключом |
| 3 | Цепочка доверия | Root CA → Intermediate CA → Leaf, алгоритм проверки цепочки, certificate bundling, особенности private PKI |
| 4 | Собственная PKI: выпуск через OpenSSL | Тестовая инфраструктура: создание корневого CA, выпуск серверного и клиентского сертификатов, файлы расширений (SAN, EKU), файл ca.srl, упаковка в PKCS#12 |
| 5 | Инспекция и проверка сертификатов | Чтение содержимого сертификата и CSR, проверка цепочки, срока действия и пары «сертификат/ключ», как проверяет rustls |
| 6 | Отзыв сертификатов | CRL, OCSP, OCSP Stapling, короткоживущие сертификаты как альтернатива отзыву |
| 7 | mTLS в Rust на rustls | Настройка клиента и сервера mTLS, отличие рукопожатия mTLS от TLS, горячая ротация сертификатов в памяти |
| 8 | Идентичность клиента: CN и SPIFFE ID | Извлечение CN из клиентского сертификата, стандарт SPIFFE, авторизация по SPIFFE ID |
| 9 | Автоматизация выпуска и ротация | Vault PKI, cert-manager, Service Mesh, доверие корню (Truststore), стратегия коротких TTL |
Что такое сертификат
Цифровой сертификат (X.509) связывает открытый ключ (public key) с идентичностью его владельца — доменом, сервисом, устройством или человеком — и заверяется цифровой подписью доверенной стороны — Удостоверяющего центра (Certificate Authority, CA).
Проще всего думать о сертификате как о паспорте: внутри — данные владельца и его открытый ключ, а подпись CA играет роль печати государства. Любой, кто доверяет CA (имеет его корневой сертификат), может убедиться, что «паспорт» настоящий, не изменялся и не просрочен. При этом сам сертификат — публичный документ; секретом является только парный ему приватный ключ.
Из чего состоит сертификат X.509
| Поле | Что содержит |
|---|---|
| Subject (субъект) | Имя владельца, например CN=myserver.local или CN=client-01 |
| Public Key (открытый ключ) | Открытый ключ владельца; парный приватный ключ хранится у владельца в секрете |
| Issuer (издатель) | Кто подписал сертификат (CA). У самоподписанного корня Issuer совпадает с Subject |
| Validity (срок действия) | Даты Not Before (с какого момента годен) и Not After (до какого) |
| Serial Number (серийный номер) | Уникальный идентификатор сертификата внутри CA; по нему сертификат отзывают — см. Отзыв |
| Signature (подпись) | Хеш данных сертификата, подписанный приватным ключом CA. Гарантирует, что данные не подменили |
| Extensions (расширения) | Дополнительные параметры — самые важные описаны ниже |
Ключевые расширения, без которых современный TLS/mTLS не работает:
- Subject Alternative Name (SAN) — альтернативные имена владельца: DNS-имена, IP-адреса, email, URI. Современные клиенты (включая
rustlsи браузеры) сверяют имя сервера только с SAN, поле CN для этого давно не используется. В SAN как URI записывается и SPIFFE ID; - Extended Key Usage (EKU) — назначение ключа: для сервера обязателен
serverAuth, для mTLS-клиента —clientAuth.rustlsстрого проверяет это поле и оборвет соединение при несоответствии; - Basic Constraints — флаг
CA:TRUE/CA:FALSE: имеет ли сертификат право подписывать другие сертификаты. Подробнее — в Цепочке доверия и Собственной PKI.
Форматы и расширения файлов
| Формат | Тип | Где встречается |
|---|---|---|
| PEM | Текстовый (Base64 между -----BEGIN ...----- / -----END ...-----) | Основной формат в OpenSSL, nginx, rustls (через rustls-pemfile). Обычно расширения .pem, .crt, .key |
| DER | Бинарный (ASN.1) | Java, встраиваемые системы; именно DER-представление сертификата парсится в Rust-коде крейтом x509-parser |
PKCS#12 (.p12, .pfx) | Контейнер: сертификат + приватный ключ + цепочка, защищен паролем | Импорт клиентских сертификатов в браузеры, Windows/macOS, мобильные приложения |
PKCS#7 (.p7b) | Контейнер только для сертификатов (без ключей) | Обмен цепочками сертификатов, подпись S/MIME |
| JKS | Java KeyStore | Хранилище ключей и доверенных корней в Java-приложениях |
Расширение файла — лишь соглашение. .crt, .cer, .pem могут содержать одно и то же; надежный способ узнать, что внутри, — открыть файл (PEM — текст) или использовать команды инспекции из статьи Инспекция и проверка.
Жизненный цикл сертификата
- Генерация ключей — создается пара: приватный ключ (хранится в секрете у владельца) и открытый ключ. Выбор алгоритма — в статье Ключи и алгоритмы.
- Создание CSR (Certificate Signing Request) — файл-запрос: открытый ключ + данные о себе (Subject, SAN), подписанные собственным приватным ключом заявителя. Приватный ключ не покидает владельца.
- Подписание — CSR отправляется в CA; тот проверяет данные и подписывает их своим приватным ключом, превращая запрос в сертификат. Как это сделать руками — в статье Собственная PKI.
- Установка — сертификат и приватный ключ подключаются к серверу или клиенту; для Netgap это конфигурация
rustls— см. mTLS в Rust. - Ротация или отзыв — до истечения
Not Afterсертификат заменяется новым (Автоматизация); при компрометации — отзывается досрочно (Отзыв).
TLS и mTLS: в чем разница
| TLS (обычный HTTPS) | mTLS (mutual TLS) | |
|---|---|---|
| Сертификат сервера | Обязателен, проверяется клиентом | Обязателен, проверяется клиентом |
| Сертификат клиента | Не требуется | Обязателен, проверяется сервером |
| Кто кому доверяет | Клиент — публичным CA из системного хранилища | Обе стороны — корням, заданным в их конфигурации (публичный CA, корпоративный УЦ заказчика или тестовая private PKI) |
| Типовой сценарий | Сайт в интернете | Связь сервисов и шлюзов Netgap между собой |
Внутренние соединения Netgap используют именно mTLS: сервер отвечает только тем клиентам, чей сертификат подписан доверенным корнем из его конфигурации, а клиент отказывается говорить с сервером, не доказавшим свою подлинность. Пошаговый разбор рукопожатия — в статье mTLS в Rust на rustls.
Быстрый старт
Минимальный путь, чтобы поднять локальный mTLS-стенд для тестирования и экспериментов:
- Освоить теорию: поля сертификата, SAN/EKU, цепочка доверия — эта страница и Цепочка доверия.
- Выбрать алгоритмы ключей (CA — RSA 4096 или ECDSA P-384; сервисы — ECDSA P-256 или Ed25519) — Ключи и алгоритмы.
- Создать тестовый корневой CA с
CA:TRUE, выпустить серверный (serverAuth+ SAN) и клиентский (clientAuth) сертификаты — Собственная PKI. - Проверить каждый выпущенный файл:
openssl verify,-text,-purpose, соответствие пары «сертификат/ключ» — Инспекция и проверка. - Установить mTLS-соединение между клиентом и сервером на
rustls— mTLS в Rust. - Построить авторизацию на идентичности из сертификата (CN или SPIFFE ID) — Идентичность клиента.
- Продумать эксплуатацию: срок жизни сертификатов, ротация, отзыв — Отзыв и Автоматизация.