Основные понятия простой системы PKI

В этом руководстве я попытаюсь описать основу теории и простую реализацию системы управления ключевой информацией.

Термины

• Public Key Infrastructure (PKI) - архитектура безопасности, в которой доверие передается через подпись доверенного центра сертификации;
• Certificate Authority (CA) - сущность, выпускающая сертификаты и списки отзывов сертификатов (доверенный центр сертификации);
• Registration Authority (RA) - сущность, которая занимается регистрацией в PKI (может быть совмещена с CA);
• Certificate - открытый ключ и идентификатор пользователя, подписанные ключом CA;
• Certificate Signing Request (CSR) - запрос на выпуск сертификата, содержащий открытый ключ и идентификатор, который должен быть сертифицирован (подписан);
• Certificate Revocation List (CRL) - список отозванных сертификатов (регулярно выпускается CA);
• Certification Practice Statement (CPS) - документ, описывающий структуру и процедуры CA.

Типы CA

• Root CA - корневой центр сертификации (выпускает только сертификаты подчиненных центров сертификации);
• Intermediate CA - вспомогательный (промежуточный) центр сертификации (выпускает только сертификаты центров сертификации);
• Signing CA - выпускающий центр сертификации, выпускающий только сертификаты пользователей.

Типы сертификатов

• Root Certificate - самоподписанный сертификат корневого центра сертификации (является гарантом доверия всей данной PKI);
• CA Certificate - сертификат центра сертификации (используется для подписывания других сертификатов и списков отзывов сертификатов);
• Cross Certificate - сертификат центра сертификации, выпущенный внешним центром сертификации по отношению к данной PKI (используется для установления доверия между отдельными PKI и обычно имеет взаимный сертификат);
• User Certificate - сертификат конечного пользователя, выпущенный для одной или нескольких целей: защита электронной почты, аутентификация сервера, аутентификация клиента и т.п. (этот сертификат не может использоваться для подписывания других сертификатов).

Форматы файлов

• Privacy Enhanced Mail (PEM) - наиболее популярный формат среди сертификационных центров. Файлы PEM-сертификатов могут иметь расширение имени .pem, .crt, .cer, и .key (файл приватного ключа). Они представляют собой ASCII файлы, закодированные по схеме base64. Когда вы открываете файл формата PEM в текстовом редакторе, вы можете увидеть, что текст кода в нем начинается с тега "----- BEGIN CERTIFICATE -----" и заканчивая тегом "----- END CERTIFICATE -----". Apache и другие подобные серверы используют сертификаты в PEM формате. Обратите внимание, что в одном файле может содержатся несколько SSL сертификатов и даже приватный ключ, один под другим. В таком случае каждый сертификат отделен от остальных ранее указанными тегами BEGIN и END. Как правило, для установки SSL сертификата на Apache, сертификаты и приватный ключ должны быть в разных файлах.
• Distinguished Encoding Rules (DER) - это бинарный тип сертификата в отличии от формата PEM. В PEM формате чаще всего используется расширение файла .cer, но иногда можно встретить и расширение файла .der. Поэтому чтобы отличить SSL сертификат в формате PEM от формата DER, следует открыть его в текстовом редакторе и найти теги начала и окончания сертификата (BEGIN/END). DER сертификаты, как правило, используются на платформах Java.
• PKCS # 7 / P7B - сертификаты в формате PKCS # 7 или P7B - это файлы, которые хранятся в формате base64 ASCII и имеют расширение файла .p7b или .p7c. P7B сертификаты содержат теги начала сертификата "----- BEGIN PKCS7 ------" и его конца "----- END PKCS7 -----". Файлы в формате P7B включают в себя только ваш SSL сертификат и промежуточные SSL сертификаты. Приватный ключ при этом идет отдельным файлом. SSL сертификаты в формате PKCS # 7 / P7B поддерживают следующие платформы: Microsoft Windows и Java Tomcat.
• PFX (формат PKCS # 12) - это формат SSL сертификата PKCS # 12 или, как его еще называют, PFX сертификат - бинарный формат, при использовании которого в одном зашифрованном файле хранится не только ваш личный сертификат пользователя или сервера и промежуточные сертификаты центра сертификации, но и ваш закрытый ключ. PFX файлы, как правило, имеют расширение .pfx или .p12. Обычно, файлы формата PFX используются на Windows серверах для импорта и экспорта файлов сертификатов и вашего приватного ключа.

Important

Со временем в программном обеспечении обнаруживаются ошибки, связанные с безопасностью обработки информации. Поэтому важно использовать наиболее свежую версию OpenSSL. Чтобы узнать версию, выполните: openssl version

Настройка

В процедурах PKI (генерация, подписывание сертификатов и т.д.) нередко выполняются схожие действия, такие как установка значений "по-умолчанию" (имя организации, используемый алгоритмы шифрования и т.п.). Чтобы упростить это, такие значения можно включать в файлы конфигурации. Разумно создавать отдельные файлы конфигураций для работы с разными CA.

Следует сказать также, что в файлы конфигураций нередко имеет смысл включать наборы (секции) параметров (расширений) сертификатов согласно их целевому назначению. Например, для сертификатов электронной подписи нужно каждый раз указывать их специфическую цель применения - расширение keyUsage и его значение digitalSignature. Кроме этого расширения для сертификатов электронной подписи могут быть полезны и другие расширения. Чтобы не указывать их вручную каждый раз, целессобразно добавить в файл конфигурации данного CA секцию, содержащую нужный набор расширений и лишь указывать имя этой секции в команде выпуска сертификата.

Описание файла конфигурации

Файл конфигурации - это текстовый файл, состоящий из секций и пар параметр = значение в них. Важно отметить, что значения параметров из одной секции могут определять другие секции. Ниже приводится пример файла конфигурации для корневого CA. Подробное описание формата конфигурационного файла можно найти тут.

В конфигурации нередко встречается понятие "расширение" - это дополнительные параметры (и их значения) в сертификате. Некоторые из них могут быть критически важными (помечены флагом critical) и, соответсвенно, при их несоответствии сертификат будет признаваться как недействительный.

root-ca.conf

# Секция [default] определяет глобальные константы, на которые можно ссылаться
# в других секциях во всем файле.

[ default ]

# Имя CA
ca = root-ca

# Имя корневой директории
dir = .

# Следующая секция используется для команды req. Здесь определяются параметры
# ключей CA, уникальное имя (DN) и дополниельные параметры для сертификата CA.

[ req ]

# Размер ключа RSA
default_bits = 2048

# Шифровать ли закрытый ключ
encrypt_key = yes

# Используемый алгоритм хэширования
default_md = sha1

# Рассматривать все строковые значения как ASCII
utf8 = no

# Не запрашивать ввод значений полей сертификата и брать значения из файла конфигурации
prompt = no

# Секция описания уникального имени (DN)
distinguished_name = ca_dn

# Секция расширений сертификата
req_extensions = ca_reqext

[ ca_dn ]

# Домен первого уровня
0.domainComponent = "ru"

# Домен второго уровня
1.domainComponent = "ИМЯ"

# Название организации
organizationName = "НАЗВАНИЕ"

# Название подразделения
organizationalUnitName = "НАЗВАНИЕ"

# Название сервера/пользователя сертификата
commonName = "НАЗВАНИЕ"

[ ca_reqext ]

# Перечень назначений использования сертификата (для сертификата CA значение
# keyCertSign должно быть указано обязательно). Признак critical указывает на то,
# что данное расширение будет помечено как критическое.
keyUsage = critical,keyCertSign,cRLSign

# Признак того, что данный сертификат является сертификатом CA
basicConstraints = critical,CA:true

# Идентификатор ключа субъекта (hash - это один из способов задать алгоритм
# расчета такого идентификатора)
subjectKeyIdentifier = hash

# Остальная часть конфигурации используется командой ca.
# В секции CA определяются параметры и политики CA.
# https://www.openssl.org/docs/manmaster/man1/openssl-ca.html

[ ca ]

# Название главной секции CA (используется, если в командной строке
# не указано значение параметра -name)
default_ca = root_ca

[ root_ca ]

# Имя файла сертификата CA
certificate = $dir/ca/$ca.crt

# Имя файла приватного ключа CA
private_key = $dir/ca/$ca/private/$ca.key

# Имя директории, в которой будут размещены новые сертификаты
new_certs_dir = $dir/ca/$ca

# Имя файла, который будет содержать текущий серийный номер сертификата
serial = $dir/ca/$ca/db/$ca.crt.srl

 # Имя файла, который будет содержать номер в списке отозванных сертификатов
crlnumber = $dir/ca/$ca/db/$ca.crl.srl

# Имя индексного файла
database = $dir/ca/$ca/db/$ca.db

# Требование уникальности имен сертификатов (однако, если сертификаты создаются
# без имени, несколько таких сертификатов не считаются совпадающими)
unique_subject = no

# Срок действия сертификата (дней)
default_days = 3652

# Алгоритм хэширования
default_md = sha1

# Имя секции с описанием политики соответствий значений
policy = match_pol

# Добавлять ли email в поле DN
email_in_dn = no

# Требование соответствия порядка полей DN порядку полей политики
# (в основном для совместимости со старыми версиями браузеров)
preserve = no

# Формат отображения сведений о сертификате при запросе на подтверждение подписи
# (при использовании сертификата)
name_opt = ca_default

# То же, что и предыдущий параметр (для возможности указать больше полей)
cert_opt = ca_default

# Копировать ли расширения из запроса на сертификацию ключа
copy_extensions = none

# Имя секции, содержащей набор расширений
x509_extensions = signing_ca_ext

# Период (в днях) до обновления CRL (если за это время его не обновить,
# то может возникать ошибка при проверке сертификатов)
default_crl_days = 365

# Имя секции с расширениями для CRL
crl_extensions = crl_ext

# Секция политики определяет, какие части DN попадают в сертификат и при каких
# обстоятельствах в сертификации следует отказать

[ match_pol ]

# Если установлено в match, то имя домена должно быть одинаковым в ключе и сертификате
domainComponent = match

# Если установлено в match, то название организации должно быть одинаковым
# в ключе и сертификате
organizationName = match

# То же самое с именем подразделения, но в случае с optional может не соответствовать
# и/или не присутствовать
organizationalUnitName = optional

# Означает, что имя может не соответствовать, но должно присутстсовать
commonName = supplied

# Название страны может не присутствовать или не совпадать
countryName = optional

# Название региона может не присутствовать или не совпадать
stateOrProvinceName = optional

# Название города может не присутствовать или не совпадать
localityName = optional

# Адрес электронной почты может не присутствовать или не совпадать
emailAddress = optional

# В следующей секции определяется, какие типы сертификатов может создавать корневой CA.

[ root_ca_ext ]

# Цели применения создаваемых сертификатов (в данном случае только CA)
keyUsage = critical,keyCertSign,cRLSign

# Признак того, что создаваться будут сертификаты центров сертификации
basicConstraints = critical,CA:true

# Способ вычисления серийного номера ключа
subjectKeyIdentifier = hash

# В создаваемый сертификат копируется идентификатор "родителя" - данного (корневого) CA
authorityKeyIdentifier = keyid:always

# В следующей секции определяется, какие типы сертификатов может создавать
# вспомогательный CA. Параметры аналогичны описанным выше.

[ signing_ca_ext ]

keyUsage = critical,keyCertSign,cRLSign

# Для вспомогательного CA устанавливается ограничение - нельзя выпускать
# сертификаты других CA
basicConstraints = critical,CA:true,pathlen:0

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid:always

# Расширения CRL существуют для того, чтобы указывать на сертификат центра,
# который выдал CRL

[ crl_ext ]

authorityKeyIdentifier  = keyid:always

Рассмотрим пример файла конфигурации вспомогательного центра сертификации:

signing-ca.conf

[ default ]

ca  = signing-ca
dir = .

[ req ]

default_bits = 2048
encrypt_key = yes
default_md = sha1
utf8 = yes
string_mask = utf8only
prompt = no
distinguished_name = ca_dn
req_extensions = ca_reqext

[ ca_dn ]

0.domainComponent = "доменное имя первого уровня"
1.domainComponent = "...второго уровня"
organizationName = "НАЗВАНИЕ КОМПАНИИ"
organizationalUnitName = "НАЗВАНИЕ ПОДРАЗДЕЛЕНИЯ"
commonName = "НАЗВАНИЕ СЕРТИФИКАТА"

[ ca_reqext ]

keyUsage = critical,keyCertSign,cRLSign
basicConstraints = critical,CA:true,pathlen:0
subjectKeyIdentifier = hash

[ ca ]

default_ca = signing_ca

[ signing_ca ]

certificate = $dir/ca/$ca.crt
private_key = $dir/ca/$ca/private/$ca.key
new_certs_dir = $dir/ca/$ca
serial = $dir/ca/$ca/db/$ca.crt.srl
crlnumber = $dir/ca/$ca/db/$ca.crl.srl
database = $dir/ca/$ca/db/$ca.db
unique_subject = no
default_days = 730
default_md = sha1
policy = match_pol
email_in_dn = no
preserve = no
name_opt = ca_default
cert_opt = ca_default
copy_extensions = copy
x509_extensions = email_ext
default_crl_days = 7
crl_extensions = crl_ext

[ match_pol ]

domainComponent = match
organizationName = match
organizationalUnitName = optional
commonName = supplied

[ any_pol ]

domainComponent = optional
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

[ email_ext ]

keyUsage = critical,digitalSignature,keyEncipherment
basicConstraints = CA:false
extendedKeyUsage = emailProtection,clientAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

[ server_ext ]

keyUsage = critical,digitalSignature,keyEncipherment
basicConstraints = CA:false
extendedKeyUsage = serverAuth,clientAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

[ crl_ext ]

authorityKeyIdentifier  = keyid:always

Построение простой PKI

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

useradd username
passwd username
login username

Все дальнейшие операции будут выполняться от имени созданного пользователя.

Создадим директории для размещения сертификата CA, служебных файлов (БД сертификатов), выпускаемых сертификатов и списков отзывов:

cd ~
mkdir -p ca/root-ca/private ca/root-ca/db crl certs

Разрешим только владельцу (например, текущему пользователю) доступ к этим директориям и их содержимому:

chmod 700 ca/root-ca/private

Создадим базу данных (фактически, это несколько файлов, содержащих список сертификатов, их сроки действия, имена, серийные номера и т.п.):

cp /dev/null ca/root-ca/db/root-ca.db
cp /dev/null ca/root-ca/db/root-ca.db.attr
echo 01 > ca/root-ca/db/root-ca.crl.srl
echo 01 > ca/root-ca/db/root-ca.crt.srl

База данных должна быть создана до того, как будут созданы какие-либо сертификаты. Общий объем базы данных должен целиком помещаться в оперативной памяти. Обратите внимание, что крайние две команды записывают серийные номера для следующего выпускаемого сертификата и следующего отзываемого сертификата (в обоих случаях 01).

Создание сертификата корневого CA

Создание запроса на выпуск сертификата

Команда openssl req -new создает закрытый ключ и запрос на выпуск (подпись) сертификата. При этом будет запрошен ввод пароля для защиты закрытого ключа. Параметры создаваемого сертификата будут заданы файлом конфигурации (т.к. мы укажем соответствующую опцию командной строки):

openssl req -new -config etc/root-ca.conf -out ca/root-ca.csr -keyout ca/root-ca/private/root-ca.key

Здесь стоит обратить внимание на то, что должны быть указаны корректные пути к файлу конфигурации root-ca.conf и создаваемым файлам запроса и закрытого ключа. Также стоит отметить, что при генерации ключа будет запрошен ввод пароля - не стоит его игнорировать.

Создание сертификата

Команда openssl ca создаст сертификат корневого CA на базе созданного ранее запроса. Этот сертификат является самоподписанным и представляет основу доверия ко всей PKI. Параметры создания сертификата будут также взяты из файла конфигурации:

openssl ca -selfsign -config etc/root-ca.conf -in ca/root-ca.csr -out ca/root-ca.crt -extensions root_ca_ext

Для выпуска сертификата потребуется ввести пароль закрытого ключа и подтвердить подпись (заверение) сертификата закрытым ключом (в данном случае тем же самым, т.к. сертификат самоподписанный).

Интересно рассмотреть результаты проделанной процедуры, т.к. они будут характерны и при выпуске иных сертификатов. Во-первых, после создания запроса на выпуск сертификата будут созданы два файла: root-ca.csr (запрос на выпуск) и root-ca.key (закрытый ключ). Во-вторых, после выпуска сертификата будут созданы следующие файлы: root-ca.crt (файл сертификата) и 01.pem (также файл сертификата в формате x509). Кроме этого, файл root-ca.crt.srl будет теперь содержать значение 02 (серийный номер следующего сертификата, который будет выпущен в будущем), root-ca.crt.srl.old (прежний файл с серийным номером), и в файл root-ca.db будет добавлена строка с описанием выпущенного сертификата, содержащая в том числе его серийный номер.

Создание сертификата вспомогательного CA

Создание базы данных

Этот шаг аналогичен такому же, описанному для сертификата корневого CA:

mkdir -p ca/signing-ca/private ca/signing-ca/db crl certs
chmod 700 ca/signing-ca/private
cp /dev/null ca/signing-ca/db/signing-ca.db
cp /dev/null ca/signing-ca/db/signing-ca.db.attr
echo 01 > ca/signing-ca/db/signing-ca.crt.srl
echo 01 > ca/signing-ca/db/signing-ca.crl.srl

Создание запроса на выпуск сертификата

Выполняется аналогично созданию запроса на выпуск сертификата корневого CA:

openssl req -new -config etc/signing-ca.conf -out ca/signing-ca.csr -keyout ca/signing-ca/private/signing-ca.key

Здесь используется файл конфигурации вспомогательного центра сертификации. Также, при создании ключа будет запрошен ввод пароля для данного ключа.

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

openssl ca -config etc/root-ca.conf -in ca/signing-ca.csr -out ca/signing-ca.crt -extensions signing_ca_ext

Используется та же команда openssl ca, но обратите внимание на то, что тут применятся конфигурация корневого CA, так как выпускаемый сертификат подписывается при помощи ключа сертификата корневого CA. Соответственно, для заверения выпускаемого сертификата потребуется ввести пароль ключа корневого центра сертификации. Также обратите внимание на то, что здесь используются другие расширения.

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

Выпуск клиентских сертификатов

Выпуск сертификата защиты электронной почты

Сначала нужно создать запрос на выпуск сертификата. Он состоит файла запроса и файла закрытого ключа. Также здесь используется файл конфигурации клиента, специально созданный для этой задачи. Он описан ниже команды.

openssl req -new -config etc/email.conf -out certs/fred.csr -keyout certs/fred.key

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

email.conf

[ req ]

default_bits = 2048
encrypt_key = yes
default_md = sha1
utf8 = yes
string_mask = utf8only
prompt = yes
distinguished_name = email_dn
req_extensions = email_reqext

[ email_dn ]

0.domainComponent = "1. Domain Component         (eg, com)      "
1.domainComponent = "2. Domain Component         (eg, company)  "
2.domainComponent = "3. Domain Component         (eg, pki)      "
organizationName = "4. Organization Name        (eg, company)  "
organizationalUnitName = "5. Organizational Unit Name (eg, section)  "
commonName = "6. Common Name              (eg, full name)"
commonName_max = 64
emailAddress = "7. Email Address            (eg, name@fqdn)"
emailAddress_max = 40

[ email_reqext ]

keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = emailProtection,clientAuth
subjectKeyIdentifier = hash
subjectAltName = email:move

После того, как создан запрос, можно выпустить сам сертификат:

openssl ca -config etc/signing-ca.conf -in certs/username.csr -out certs/username.crt -extensions email_ext

Обратите внимание, что в команде на выпуск сертификата указаны файл запроса на выпуск, целевой файл сертификата, имя файла конфигурации вспомогательного центра сертификации. Кроме этого, указано имя секции в этом файле, определяющее набор расширений для данного сертификата.

Еще один интересный момент. При генерации запроса нужно было ввести ряд полей сертификата (согласно файлу конфигурации). Теперь, при выпуске сертификата, эти поля будут проверяться согласно политике соответствия в файле конфигурации для данного типа сертификатов для данного CA. Например, в файле конфигурации CA указаны расширения domainComponent и organizationName со значением match. Это значит, что если пользователь введет в своем запросе для данных расширений значения, отличные от ожидаемых сервером сертификации, то в выпуске будет отказано. А сервер сертификации ожидает получить значения, которые указаны в секции DN. Таким образом, в запросе на выпуск клиентского сертификата должны быть указаны в точности (требование match), или указанны хоть какие-то (требование supplied), значения соответствующих расширений.

Выпуск сертификата для сервера

Рассмотрим еще один пример выпуска сертификата для web-сервера. Вначале приведем пример файла конфигурации для этой процедуры:

web-server.conf

[ default ]

SAN = DNS:yourdomain.tld

[ req ]

default_bits = 2048
encrypt_key = no
default_md = sha1
utf8 = yes
string_mask = utf8only
prompt = yes
distinguished_name = server_dn
req_extensions = server_reqext

[ server_dn ]

0.domainComponent = "1. Domain Component         (eg, com)      "
1.domainComponent = "2. Domain Component         (eg, company)  "
2.domainComponent = "3. Domain Component         (eg, pki)      "
organizationName = "4. Organization Name        (eg, company)  "
organizationalUnitName = "5. Organizational Unit Name (eg, section)  "
commonName = "6. Common Name              (eg, FQDN)     "
commonName_max = 64

[ server_reqext ]

keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth
subjectKeyIdentifier = hash
subjectAltName = $ENV::SAN

Создаем запрос на выпуск сертификата:

SAN=DNS:www.simple.org openssl req -new -config etc/web-server.conf -out certs/simple.org.csr -keyout certs/simple.org.key

Заметьте, что в командной строке мы указываем значение некоей переменной SAN. Это имя также присутствует в файле конфигурации. На самом деле это просто удобный способ гибко передавать в конфигурацию значение одного из расширений сертификата. SAN - это "Subject Alternative Names" - альтернативные имена субьекта. Их может быть множество и все могут содержаться в одном сертификате. Это отличный способ сэкономить при выпуске платных сертификатов. Также стоит отметить, что при генерации закрытых ключей серверов пароли как правило не используются, т.к. серверы запускаются автоматически, а требование на ввод пароля прервет запуск.

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

openssl ca -config etc/signing-ca.conf -in certs/simple.org.csr -out certs/simple.org.crt -extensions server_ext

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

Отзыв сертификата

Поводов для отзыва сертификата может быть множество: начиная от завершения срока действия сертификата, до утери клиентом его ключа или компрометации. Чтобы отозвать сертификат, сделав его недоверенным для данной PKI. Для этого есть команда openssl ca -revoke. Сертификат отзывают по его серийному номеру, который можно легко найти в файле базы данных. Например, отзовем сертификат 01:

openssl ca -config etc/signing-ca.conf -revoke ca/signing-ca/01.pem -crl_reason superseded

Для отзыва сертификата нужно ввести пароль ключа сертификата вспомогательного центра сертификации. После этой команды сертификат будет помечен в файле базы данных как отозванный. Но чтобы отзыв сертификата нашел отражение в работе самой PKI, нужно создать и распространить список отзывов сертификатов. Для этого используется команда openssl ca -gencrl, которая создает файл со списком отозванных сертификатов. Эту команду стоит выполнять регулярно.

openssl ca -gencrl -config etc/signing-ca.conf -out crl/signing-ca.crl

Сохранение сертификатов в разных форматах

Сохранение в формат DER

Согласно RFC-2585, все публикуемые сертификаты должны распространяться в этом формате.

openssl x509 -in certs/fred.crt -out certs/fred.cer -outform der

При этом также и список отзывов нужно сохранять в формате DER:

openssl crl -in crl/signing-ca.crl -out crl/signing-ca.crl -outform der

Сохранение в формате PKCS#7

openssl crl2pkcs7 -nocrl -certfile ca/signing-ca.crt -certfile ca/root-ca.crt -out ca/signing-ca-chain.p7c -outform der

В таком формате в можно сохранить несколько сертификатов за одну выгрузку.

Сохранение в формате PKCS#12

openssl pkcs12 -export -name "Fred Flintstone" -inkey certs/fred.key -in certs/fred.crt -out certs/fred.p12

Таким образом можно сохранить вместе с сертификатом его ключ и даже дополнительные сертификаты, составляющие полную цепочку вплоть до корневого CA.

Сохранение в формате PEM

cat ca/signing-ca.crt ca/root-ca.crt > ca/signing-ca-chain.pem
cat certs/username.key certs/username.crt > certs/username.pem

Дополнительные возможности

Просмотр содержимого запроса:

openssl req -in certs/fred.csr -noout -text

Просмотр сертификата:

openssl x509 -in certs/fred.crt -noout -text

Просмотр списка отзывов:

openssl crl -in crl/signing-ca.crl -noout -text

Краткое резюме

Таким образом, на примере создания простой PKI можно проследить логику работы инфраструктуры.

Ключевым элементом доверия всей системы является сертификат (а если быть точнее - ключ, и созданный на его основании самоподписанный сертификат) корневого центра сертификации. Если будет скомпрометирован этот ключ, могут быть созданы другие центры сертификации и любые клиенты. Таким образом, имеет смысл создав этот сертификат и выпустив на его основании сертификат вспомогательного центра сертификации, хранить его наиболее защищенным способом. Сертификат же (и ключ) вспомогательного центра сертификации стоит выдать ответственному сотруднику, который будет заниматься обслуживанием PKI: выпуском и отзывом клиентских сертификатов и ведением соответствующего учета. В любом случае, все действия по работе с PKI должны быть строго детерминированы и обеспечено их документирование.

Клиентские ключи и запросы на выдачу сертификатов могут быть сгенерированы самими клиентами. Так может быть обеспечена, например, конфиденциальность их паролей. В наиболее простых, или специфических, случаях, клиентские сертификаты могут быть полностью выпущены ответственным за работу с PKI.

В идеале должен быть написан документ, в котором определяются роли ответственных и описываются все процедуры. Хорошей идеей является документирование процедуры формализации параметров выпускаемых сертификатов, чтобы исключить произвол при их создании.