OpenSSL Certificate Authority. Центр сертификации OpenSSL.
Вольный перевод с источника
Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.
Вступление
OpenSSL — это криптографическая библиотека со свободным и открытым исходным кодом, которая предоставляет несколько инструментов командной строки для работы с цифровыми сертификатами. Некоторые из этих инструментов могут быть использованы в качестве центра сертификации.
Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.
В некоторых случаях имеет больше смысла выступать в качестве вашего собственного центра сертифкации, чем платить центрам сертификации, таким как DigiCert. Например, обеспечение безопасности вебсайта в интранете или для выдачи собственных сертификатов клиентам, чтобы позволить им проверять подлинность сервера (Apache, OpenVPN).
Создание корневой пары ключей
Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.
Как правило, корневой центр сертификации не подписывает напрямую серверные или клиентские сертификаты. Корневой центр сертификации используется только для создания одного или нескольких промежуточных центров сертификации, которые являются доверенными корневому центру сертификации чтоб подписывать сертификаты от их имени. Это является лучшей практикой. Таким образом, корневой ключ может хранится «оффлайн» и по-максимому не использоваться, так как любая компрометация губительна для ключа. В качестве примера лучшей практики является создание корневой пары в максимально защищенной среде. В идеале это будет полностью зашифрованный, физически изолированный компьютер, который постоянно отключен от интернета. Следует вынуть беспроводную сетевую карту, а порт обычной сетевой карты залить клеем.
Подготовка каталогов
Выберите каталог для хранения всех ключей и сертификатов. К примеру, /root/ca (все производится на Ubuntu 14.04.3 LTS)
mkdir /root/ca
Создадим структуру каталогов. Файлы index.txt и serial будут выступать в качестве плоской базы для отслеживания подписанных сертификатов.
# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Подготовка конфигурационных файлов
Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf, скопируем в него следующее содержимое root-config.txt.
Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default]:
[ ca ]
#man ca
default_ca = CA_default
Раздел [CA_default] содержит ряд значений по умолчанию:
[ CA_default ]
# Directory and file locations.
dir = /root/ca
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = $dir/serial
RANDFILE = $dir/private/.rand
# The root key and root certificate.
private_key = $dir/private/ca.key.pem
certificate = $dir/certs/ca.cert.pem
# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/ca.crl.pem
crl_extensions = crl_ext
default_crl_days = 30
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = 375
preserve = no
policy = policy_strict
Policy_strict будет применяться для всех подписей корневого центра сертификации, и корневой центр сертификации будет использоваться только для создания промежуточных центров сертификации.
[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of man ca.
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Применим policy_loose для всех подписей промежуточных центров серфтификации, так как промежуточные центры сертификации это подписывающие серверы, и клиентские сертификаты могут приходить от различных третьих лиц.
[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.
[ req ]
# Options for the `req` tool (`man req`).
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
# Extension to add when the -x509 option is used.
x509_extensions = v3_ca
Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.
[ req_distinguished_name ]
# See https://en.wikipedia.org/wiki/Certificate_signing_request.
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
emailAddress = Email Address
# Optionally, specify some defaults.
countryName_default = GB
stateOrProvinceName_default = England
localityName_default = England
organizationName_default = Alice Ltd
#organizationalUnitName_default =
#emailAddress_default =
Следующие несколько секций являются расширениями, которые могут применять при подписывании сертификатов. Например, при указании аргумента командной строки -extensions v3_ca будут применены расширения из секции [ v3_ca ]. Эти расширения будут применяться при создании корневого сертификата.
[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
При создании сертификата промежуточного центра сертификации будут применяться расширения из v3_ca_intermediate. Параметр pathlen:0 указывает, что не может быть никаких дальнейших центров сертификации ниже промежуточного центра сертификации.
[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
Расширение usr_cert будет применяться при подписывании клиентских сертификатов, таких, которые используются для аутентификации удаленных пользователей.
[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
Расширение server_cert будет применяться при подписывании серверных сертификатов, таких, которые используются для веб-серверов.
[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
Расширение crl_ext будет автоматически применяться при создании списков отзыва сертификатов (CRL — certificate revocation lists).
[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always
Расширение ocsp будет применяться при подписывании сертификата OCSP (Online Certificate Status Protocol, онлайн протокол статуса сертификатов).
[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
Создание корневого ключа
Создадим корневой ключ (ca.key.pem), который следует хранить защищенно. Любой, владеющий корневым ключом, может выдавать доверенные сертификаты. Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем. Следует использовать 4096 битное шифрование для ключей корневого и промежуточных центров сертификации. Серверные и клиентские сертификаты возможно подписывать шифрованием с меньшей битностью.
# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096
Enter pass phrase for ca.key.pem: secretpassword
Verifying - Enter pass phrase for ca.key.pem: secretpassword
# chmod 400 private/ca.key.pem
Создание корневого сертификата
Для создания корневого сертификата (ca.cert.pem) используется корневой ключ (ca.key.pem). Следует указать длинный срок годности сертификата, например, 20 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными. Всякий раз при использовании утилиты req следует указывать файл конфигурации для использования с опцией –config, в противном случае OpenSSL будет использовать по умолчанию конфигурационный файл /etc/pki/tls/openssl.cnf!
# cd /root/ca
# openssl req -config openssl.cnf \
-key private/ca.key.pem \
-new -x509 -days 7300 -sha256 -extensions v3_ca \
-out certs/ca.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Root CA
Email Address []:
# chmod 444 certs/ca.cert.pem
Проверка корневого сертификата
# openssl x509 -noout -text -in certs/ca.cert.pem
Вывод показывает:
- Используемый алгоритм Signature Algorithm
- Даты периода действия сертификата Validity
- Длину публичного ключа Public-Key
- Эмитент сертификата Issuer, который является объектом, который подписал сертификат
- Предмет Subject, который относится к самому сертификату.
Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Validity
Not Before: Apr 11 12:22:58 2015 GMT
Not After : Apr 6 12:22:58 2035 GMT
Subject: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca, и опции из секции [ v3_ca ] отражены в выводе.
X509v3 extensions:
X509v3 Subject Key Identifier:
38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Authority Key Identifier:
keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Создание промежуточной пары ключей
Промежуточным центомр сертификации является объект, который может подписывать сертификаты от имени корневого центра сертификации. Корневой центр сертификации подписывает промежуточный сертификат, образуя цепочку доверия.
Цель использования промежуточного центра сертификации, прежде всего, для обеспечения безопасности. Корневой ключ должен храниться «оффлайн» и использоваться как можно реже. Если промежуточный ключ будет скомпрометирован, корневой центр сертификации может отозвать промежуточный сертификат и создать новую промежуточную криптографическую пару.
Подготовка каталогов
Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.
# mkdir /root/ca/intermediate
Создадим точно такую же структуру каталогов, которая используется для корневого центра сертификации. Также удобно создать каталог csr для хранения запросов на подпись сертификатов.
# cd /root/ca/intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Добавим файл crlnumber к дереву каталогов промежуточного центра сертификации. Crlnumber будет использоваться для отслеживания списков отзывов сертификатов.
# echo 1000 > /root/ca/intermediate/crlnumber
Создадим конфигурационный файл /root/ca/intermediate/openssl.cnf, скопируем в него следующее содержимое intermediate-config.txt. В нем изменены пять опций, по сравнению с конфигурационным файлов корневого центра сертификации:
[ CA_default ]
dir = /root/ca/intermediate
private_key = $dir/private/intermediate.key.pem
certificate = $dir/certs/intermediate.cert.pem
crl = $dir/crl/intermediate.crl.pem
policy = policy_loose
Создание промежуточного ключа
Создадим промежуточный ключ (intermediate.key.pem). Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем.
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/intermediate.key.pem 4096
Enter pass phrase for intermediate.key.pem: secretpassword
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword
# chmod 400 intermediate/private/intermediate.key.pem
Создание промежуточного сертификата
Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци (intermediate/openssl.cnf).
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
-key intermediate/private/intermediate.key.pem \
-out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:
Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации (/root/ca/openssl.cnf).
# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
-days 3650 -notext -md sha256 \
-in intermediate/csr/intermediate.csr.pem \
-out intermediate/certs/intermediate.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y
# chmod 444 intermediate/certs/intermediate.cert.pem
Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.
V 250408122707Z 1000 unknown ... /CN=Alice Ltd Intermediate CA
Проверка промежуточного сертификата
Как мы делали с корневым сертификатом, убедимся, что детали промежуточного сертификата корректны.
# openssl x509 -noout -text \
-in intermediate/certs/intermediate.cert.pem
Сверим промежуточный сертификат с корневым сертификатом. ОК показывает, что цепочка доверия не повреждена.
# openssl verify -CAfile certs/ca.cert.pem \
intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK
Создание файла цепочки сертификатов
Когда приложение (например, веб-браузер) пытается проверить сертификат, подписанный промежуточным центром сертификации, оно также должно проверить промежуточный сертификат от корневого центра сертификации. Для выполнения проверки цепочки доверия создадим цепочку сертификатов центра сертификации для предоставления приложениям.
Чтобы создать цепочку сертификатов требуется объеденить промежуточные и корневые сертификаты вмете. Позже мы будем использовать этот файл для проверки сертификатов подписанных промежуточным центром сертификации.
# cat intermediate/certs/intermediate.cert.pem \
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem
Наш файл цепочки сертификатов должен содержать корневой сертификат, потому что клиентские приложения ничего не знают о нем. Лучшим вариантом, особенно, если вы администратор сети, является установка корневого сертификата на каждом клиенте, которому требуется подключаться к приложению.
Подписывание серверного и клиентского сертификатов
Подпишем сертификаты используя наш промежуточный центр сертификации. Эти подписанные сертификаты можно использовать в различных ситуациях, таких как защищать соединения к веб серверу или аутентифицировать клиентов, присоединяющихся к сервису.
Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.
Создание ключа
Наши корневая и промежуточная пары 4096 бит. Серверный и клиентский сертификат обычно истекают после одного года, поэтому мы можем безопасно использовать 2048 бит.
Хотя 4096 бит немного больше безопаснее, чем 2048 бит, он замедляет TLS хэндшейки и значительно увеличивает нагрузку на процессор во время хэндшейков. По этой причине, большинство веб-сайтов используют 2048-битные пары ключей.
Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/www.example.com.key.pem 2048
# chmod 400 intermediate/private/www.example.com.key.pem
Создание сертификата
Используем частный ключ для создания запроса на подписывание сертификата (CSR). Детали в CSR не обязательно должны совпадать с промежуточным центром сертификации. Для серверных сертификатов, Общее Имя (Common Name) должно быть полным доменным именем (fully qualified domain name — FQDN) (к примеру, www.example.com), в то время как для клиентского сертификата оно должно быть любым уникальным идентификатором (к примеру, e-mail адресом). Common Name не может быть таким же, как любой корневой или промежуточный сертификат.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/www.example.com.key.pem \
-new -sha256 -out intermediate/csr/www.example.com.csr.pem
Enter pass phrase for www.example.com.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:US
State or Province Name []:California
Locality Name []:Mountain View
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Web Services
Common Name []:www.example.com
Email Address []:
Для создания сертификата воспользуемся промежуточным центром сертификации для подписи CSR. Если сертификат будет использоваться на сервере, используйте расширение server_cert. Если сертификат будет использоваться для аутентификации клиентов, то используйте расширение usr_cert. Сертификаты обычно даются сроком на один год, на центре сертификации обычно дают несколько дней для удобства.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in intermediate/csr/www.example.com.csr.pem \
-out intermediate/certs/www.example.com.cert.pem
# chmod 444 intermediate/certs/www.example.com.cert.pem
Файл intermediate/index.txt должен содержать строку, которая относится к этому сертификату
V 160420124233Z 1000 unknown ... /CN=www.example.com
Проверка сертификата
# openssl x509 -noout -text \
-in intermediate/certs/www.example.com.cert.pem
Issuer сертификата наш промежуточный центр сертификации. Subject относится к самому сертификату.
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Intermediate CA
Validity
Not Before: Apr 11 12:42:33 2015 GMT
Not After : Apr 20 12:42:33 2016 GMT
Subject: C=US, ST=California, L=Mountain View,
O=Alice Ltd, OU=Alice Ltd Web Services,
CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Вывод также покажет расширения X509V3. При создании сертификата можно использовать расширения server_cert или usr_cert. Варианты о соответствующем разделе конфигурации будут отражаться в выводе.
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
B1:B8:88:48:64:B7:45:52:21:CC:35:37:9E:24:50:EE:AD:58:02:B5
X509v3 Authority Key Identifier:
keyid:69:E8:EC:54:7F:25:23:60:E5:B6:E7:72:61:F1:D4:B9:21:D4:45:E9
DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate Authority/CN=Alice Ltd Root CA
serial:10:00
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Используя файл цепочки сертификатов центра сертификации, который мы создали ранее (ca-chain.cert.pem) для проверки того, что новый сертификат имеет действительную цепочку доверия.
# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
intermediate/certs/www.example.com.cert.pem
www.example.com.cert.pem: OK
Установка сертификата
Теперь можно установить новый сертификат на сервере, или распространить сертификат на клиентов. При установке на серверное приложение (к примеру, Apache), понадобятся следующие файлы:
- ca-chain.cert.pem
- example.com.key.pem
- example.com.cert.pem
Если вы подписывали CSR от стороннего лица, у вас нет доступа до их частного ключа, и вы должны им дать только файл цепочки ca-chain.cert.pem и сертификат www.example.com.cert.pem.
Списки отзывов сертификатов
Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.
Публикация CRL в публично доступном месте (к примеру, http://example.com/intermediate.crl.pem) позволит треьтим сторонам получать CRL из этого места, чтобы проверить, нет ли в нем сертификатов, которые могут быть отозваны. Некоторые разработчики приложений вместо устаревшего CRL используют Онлайн Протокол Статуса Сертификата (Online Certificate Status Protocol — OCSP).
Подготовка файла конфигурации
Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert.
[ server_cert ]
# ... snipped ...
crlDistributionPoints = URI:http://example.com/intermediate.crl.pem
Создание CRL
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-gencrl -out intermediate/crl/intermediate.crl.pem
Секция CRL OPTIONS в man ca содержит больше информации о том, как создавать CRL.
Можно проверить содержимое CRL с помощтю утилиты crl.
# openssl crl -in intermediate/crl/intermediate.crl.pem -noout –text
Пока еще не было отозванных сертификатов, поэтому в выводе указано:
No Revoked Certificates.
Необходимо пересоздавать CRL на регулярной основе. По умолчанию, CRL истекает через 30 дней. Это настраивается опцией default_crl_days в секции CA_default.
Отзыв сертификата
Давайте разберем пример. Алиса запустила веб-сервер Apache и имеет личную папку с сердцу трогательными милыми картинками котят. Алиса хочет предоставить своему другу, Бобу, доступ к этой коллекции.
Боб создает запрос частного ключа и запрос на подпись сертификата (CSR).
$ cd /home/bob
$ openssl genrsa -out bob@example.com.key.pem 2048
$ openssl req -new -key bob@example.com.key.pem \
-out bob@example.com.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name [XX]:US
State or Province Name []:California
Locality Name []:San Francisco
Organization Name []:Bob Ltd
Organizational Unit Name []:
Common Name []:bob@example.com
Email Address []:
Боб посылает свой CSR Алисе которая затем подписывает его.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-extensions usr_cert -notext -md sha256 \
-in intermediate/csr/bob@example.com.csr.pem \
-out intermediate/certs/bob@example.com.cert.pem
Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n]: y
Алиса проверяет, что сертификат действителен:
# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
intermediate/certs/bob@example.com.cert.pem
bob@example.com.cert.pem: OK
Файл index.txt должен содержать новую запись.
V 160420124740Z 1001 unknown ... /CN=bob@example.com
Алиса посылает Бобу подписанный сертификат. Боб устанавливает сертификат в своем веб-браузере и теперь у него есть доступ к фотографиям котят Алисы. Ура!
К сожалению, выясняется, что Боб себя плохо вел. Боб отправил фотографии котят Алисы в Hacker News, заявляя, что они его и теперь набирает огромную популярность. Алиса это узнает и нуждается в немедленном отзыве его доступа.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-revoke intermediate/certs/bob@example.com.cert.pem
Enter pass phrase for intermediate.key.pem: secretpassword
Revoking Certificate 1001.
Data Base Updated
Строка в index.txt, которая относится к сертификату Боба теперь начинается с буквы R. Это означает, что он был отозван (Revoked).
R 160420124740Z 150411125310Z 1001 unknown ... /CN=bob@example.com
После отзыва сертификата Боба, Алисе необходимо пересоздать CRL.
Ипользование CRL на сервере
Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.
В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify, и можно блокировать клиентов, чьи сертификаты были отозваны.
Использование CRL клиентами
Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.
Если сертификат был подписан с расширением, которое включает crlDistributionPoints, клиентское приложение может прочитать эту информацию и получить CRL из указанного места.
Точки распространения CRL видны в спецификациях X509v3 сертификата.
# openssl x509 -in cute-kitten-pictures.example.com.cert.pem -noout -text
X509v3 CRL Distribution Points:
Full Name:
URI:http://example.com/intermediate.crl.pem
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.
Когда центр сертификации подписывает сертификат, он обычно включает адрес сервера OCSP (к примеру, http://ocsp.example.com) в в сертификат. Это похоже на функцию crlDistributionPoints, используемой для CRL.
Например, когда веб-браузеру предоставлен сертификат сервера, он посылает запрос на адрес сервера OCSP, указанном в сертификате. По этому адресу OCSP слушает запросы и отвечает статусом отзыва сертификата.
Рекомендуется использовать OCSP вместо CRL, где это возможно, хотя реально, как правило, OCSP нужен только для сертификатов веб-сайтов. Некоторыми веб-браузерами поддержка CRL считается устаревшей, или вообще убрана.
Подготовка конфигурационного файлы
Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert.
[ server_cert ]
# ... snipped ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com
Создание пары OCSP
Ответчик OCSP нуждается в криптографической паре для подписывания ответа, который посылается запрашивающей стороне. Криптографическая пара OCSP должна быть подписана на том же центре сертификации, на котором проверяется подписанный сертификат.
Создадим частный ключ и зашифруем его алгоритмом AES-256.
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/ocsp.example.com.key.pem 4096
Создадим запрос на создание сертификата (CSR). Детали должны, как правило, совпадать с подписывающим центром сертификации. Common Name, однако, должен быть полным доменным именем.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
-key intermediate/private/ocsp.example.com.key.pem \
-out intermediate/csr/ocsp.example.com.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:ocsp.example.com
Email Address []:
Подпишем CSR промежуточным центром сертификации.
# openssl ca -config intermediate/openssl.cnf \
-extensions ocsp -days 375 -notext -md sha256 \
-in intermediate/csr/ocsp.example.com.csr.pem \
-out intermediate/certs/ocsp.example.com.cert.pem
Проверим, что сертификат содержит коррестные расширения X509v3.
# openssl x509 -noout -text \
-in intermediate/certs/ocsp.example.com.cert.pem
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage: critical
OCSP Signing
Отзыв сертификата
Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.
Создадим серверный сертификат для тестирования.
# cd /root/ca
# openssl genrsa -out intermediate/private/test.example.com.key.pem 2048
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/test.example.com.key.pem \
-new -sha256 -out intermediate/csr/test.example.com.csr.pem
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in intermediate/csr/test.example.com.csr.pem \
-out intermediate/certs/test.example.com.cert.pem
Запустим ответчик OCSP на локальной машине. Вместо того, чтобы хранить статус отзыва в отдельном CRL файле ответчик OCSP напрямую читает файл index.txt. Ответ подписывается криптографической парой OCSP (используя опции –rkey и –rsigner).
# openssl ocsp -port 127.0.0.1:2560 -text -sha256 \
-index intermediate/index.txt \
-CA intermediate/certs/ca-chain.cert.pem \
-rkey intermediate/private/ocsp.example.com.key.pem \
-rsigner intermediate/certs/ocsp.example.com.cert.pem \
-nrequest 1
Enter pass phrase for ocsp.example.com.key.pem: secretpassword
В другом терминале пошлем запрос к OCSP ответчику. Опция –cert указывает сертификат для запроса.
# openssl ocsp -CAfile intermediate/certs/ca-chain.cert.pem \
-url http://127.0.0.1:2560 -resp_text \
-issuer intermediate/certs/intermediate.cert.pem \
-cert intermediate/certs/test.example.com.cert.pem
Начало вывода показывает следующее:
- был ли получен положительный ответ (OCSP Response Status)
- идентичность ответчика (Responder Id)
- статус отзыва сертификата (Cert Status)
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: ... CN = ocsp.example.com
Produced At: Apr 11 12:59:51 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334
Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9
Serial Number: 1003
Cert Status: good
This Update: Apr 11 12:59:51 2015 GMT
Отзыв сертификата.
# openssl ca -config intermediate/openssl.cnf \
-revoke intermediate/certs/test.example.com.cert.pem
Enter pass phrase for intermediate.key.pem: secretpassword
Revoking Certificate 1003.
Data Base Updated
Как и раньше, запускаем ответчик OCSP в другом терминале и шлем запрос. В этот раз вывод показывает "Cert Status: revoked" и "Revocation Time".
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: ... CN = ocsp.example.com
Produced At: Apr 11 13:03:00 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334
Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9
Serial Number: 1003
Cert Status: revoked
Revocation Time: Apr 11 13:01:09 2015 GMT
This Update: Apr 11 13:03:00 2015 GMT