Создание и управление цепочками сертификатов

Корневой CA — это самоподписанный сертификат, служащий конечным якорем доверия. Закрытый ключ корневого CA необходимо хранить в автономном режиме — в изолированной от сети системе или HSM, — поскольку его компрометация ставит под угрозу всю PKI. Команда "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" создаёт самоподписанный корневой сертификат со сроком действия 10 лет.

Промежуточные CA подписываются корневым CA и используются для повседневной выдачи сертификатов. Сначала создайте ключ и CSR промежуточного CA: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Затем корневой CA подписывает его командой "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Сертификаты конечных узлов подписываются промежуточным CA для определённых серверов или клиентов. Создайте ключ и CSR сервера с именами альтернативных субъектов (SAN), затем подпишите их промежуточным CA: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

Закрытый ключ корневого CA хранится в автономном режиме и используется только для подписывания небольшого числа сертификатов промежуточных CA. Повседневную выдачу сертификатов выполняют подключённые к сети промежуточные CA. Если промежуточный CA скомпрометирован, его можно отозвать и заменить без компрометации корневого CA. Корневой ключ остаётся в безопасности, поскольку он никогда не был доступен через сеть.

Команда "openssl ca" предоставляет более полный рабочий процесс CA, чем "openssl x509 -req". Она поддерживает базу данных сертификатов (index.txt), назначает серийные номера из файла серийных номеров и обрабатывает создание CRL. Для неё требуется корректный конфигурационный файл openssl.cnf с разделами для конкретного CA, в которых определяются политика сертификатов и ограничения длины цепочки.

Полный файл цепочки сертификатов для веб-сервера содержит сертификат конечного узла, за которым в правильном порядке следуют сертификаты промежуточных CA; цепочка заканчивается перед корневым сертификатом. Корневые сертификаты не включаются, поскольку браузеры уже содержат хранилища корневых сертификатов. Порядок объединения: "cat server_cert.pem intermediate_cert.pem > chain.pem". Неправильный порядок приводит к сбоям рукопожатия TLS.

Команда "openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" проверяет всю цепочку. Флаг "-untrusted" указывает промежуточные сертификаты, входящие в цепочку, но ещё не являющиеся доверенными. При успешной проверке выводится "server_cert.pem: OK". Распространённые ошибки указывают на отсутствие промежуточных сертификатов или истёкший срок их действия.

К распространённым проблемам с цепочками сертификатов относятся: отсутствие промежуточных сертификатов (сервер отправляет только сертификат конечного узла), неправильный порядок объединения (сначала должен идти сертификат конечного узла), просроченный промежуточный сертификат (его легко не заметить, поскольку отслеживается срок действия сертификата конечного узла), самоподписанные сертификаты, отсутствующие в хранилище доверия, и несовпадение имени (поле SAN сертификата не совпадает с именем узла). Все эти проблемы можно диагностировать с помощью команды "openssl s_client -showcerts".

PKCS#12 (.pfx или .p12) — это формат контейнера, объединяющий закрытый ключ, сертификат конечного узла и промежуточные сертификаты в одном зашифрованном файле. Создание выполняется командой "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Этот формат требуется IIS, .NET, хранилищам ключей Java и многим корпоративным приложениям.

PEM использует кодировку base64 и ASCII, удобен для чтения, поддерживает несколько объектов в одном файле и применяется Apache, nginx и инструментами OpenSSL. DER — двоичный формат с одним объектом в файле, используемый Java (при импорте в JKS), Android и некоторыми корпоративными инструментами. PKCS#12/PFX — зашифрованный двоичный контейнер для нескольких объектов, используемый Windows и IIS. Перед развёртыванием выясните, какой формат ожидает целевая система.

Современные CA обязаны заносить все выданные сертификаты в журналы прозрачности сертификатов (CT) до их передачи владельцу. При создании частного CA для внутреннего использования ведение журналов CT не требуется. Однако общедоступные сертификаты должны содержать встроенные подписанные отметки времени сертификата (SCT), чтобы Chrome им доверял. Частные CA могут применять собственные правила без требований CT.

При сборке файла цепочки сертификатов TLS для сервера nginx в каком порядке нужно объединять сертификаты?

Корневые CA являются самоподписанными, хранятся в автономном режиме и подписывают только промежуточные CA. Промежуточные CA занимаются повседневной выдачей сертификатов. Файлы цепочек содержат сначала сертификат конечного узла, затем промежуточные сертификаты; корневой сертификат не включается. Проверяйте цепочку командой "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". Контейнеры PKCS#12 объединяют ключ и сертификаты для Windows и Java. Неправильный порядок цепочки — распространённая причина сбоев при развёртывании, которую можно диагностировать с помощью s_client -showcerts.