- Вступление
- Generate ssl certificates with subject alt names
- Online certificate status protocol
- Openssl certificate authority. центр сертификации openssl.
- X509 certificate modifying distinguished name field
- Ипользование crl на сервере
- Использование crl клиентами
- Методы определения distinguished name в домене active directory
- Подготовка каталогов
- Подготовка конфигурационного файлы
- Подготовка конфигурационных файлов
- Подготовка файла конфигурации
- Подписывание серверного и клиентского сертификатов
- Проверка корневого сертификата
- Проверка промежуточного сертификата
- Создание crl
- Создание ключа
- Создание корневого ключа
- Создание корневого сертификата
- Создание корневой пары ключей
- Создание пары ocsp
- Создание промежуточного ключа
- Создание промежуточного сертификата
- Создание промежуточной пары ключей
- Создание файла цепочки сертификатов
- Статья – проверка электронной цифровой подписи authenticode. часть 1. теория
- Установка сертификата
- Списки отзывов сертификатов
- Отзыв сертификата
Вступление
OpenSSL — это криптографическая библиотека со свободным и открытым исходным кодом, которая предоставляет несколько инструментов командной строки для работы с цифровыми сертификатами. Некоторые из этих инструментов могут быть использованы в качестве центра сертификации.
Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.
В некоторых случаях имеет больше смысла выступать в качестве вашего собственного центра сертифкации, чем платить центрам сертификации, таким как DigiCert. Например, обеспечение безопасности вебсайта в интранете или для выдачи собственных сертификатов клиентам, чтобы позволить им проверять подлинность сервера (Apache, OpenVPN).
Generate ssl certificates with subject alt names
Open ssl.conf in a text editor.
Edit the domain(s) listed under the [alt_names] section so that they match the local domain name you want to use for your project, e.g.
DNS.1 = my-project.dev
Additional FQDNs can be added if required:
DNS.1 = my-project.dev
DNS.2 = www.my-project.dev
DNS.3 = fr.my-project.dev
Create a directory for your project, e.g. my_project and save ssl.conf inside it.
Open Terminal and navigate to ‘my_project’:
cd my_project
Generate a private key:
openssl genrsa -out private.key 4096
Generate a Certificate Signing Request
openssl req -new -sha256
-out private.csr
-key private.key
-config ssl.conf
(You will be asked a series of questions about your certificate. Answer however you like, but for ‘Common name’ enter the name of your project, e.g. my_project)
Now check the CSR:
openssl req -text -noout -in private.csr
You should see this:
X509v3 Subject Alternative Name: DNS:my-project.site and
Signature Algorithm: sha256WithRSAEncryption
Generate the certificate
openssl x509 -req
-sha256
-days 3650
-in private.csr
-signkey private.key
-out private.crt
-extensions req_ext
-extfile ssl.conf
Add the certificate to keychain and trust it:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain private.crt
(Alternatively, double click on the certificate file private.crt to open Keychain Access. Your project name my_project will be listed under the login keychain. Double click it and select ‘Always trust’ under the ‘Trust’ section.)
If you are using MAMP Pro, add (or edit) a host with the server name you listed under the [alt_names] section of your ssl.conf. On the SSL tab select the Certificate file and Certificate key that you just generated.
Save changes and restart Apache.
Online certificate status protocol
Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.
Openssl certificate authority. центр сертификации openssl.
Вольный перевод с источника
Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.
X509 certificate modifying distinguished name field
Due to size limitation, I would like to alter OpenSSL configuration file so then I would be able to generate smaller x509 certificates. Is it possible? If so, I would like to have a Pseudo ID instead of all distinguished name fields. When I want to generate a self-signed certificate using the new modified config file, it gives me an error:
error, no objects specified in config file
problems making Certificate Request
29749:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:109:
Any tip would be appreciated.
Ипользование crl на сервере
Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.
В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify, и можно блокировать клиентов, чьи сертификаты были отозваны.
Использование crl клиентами
Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.
Если сертификат был подписан с расширением, которое включает crlDistributionPoints, клиентское приложение может прочитать эту информацию и получить CRL из указанного места.
Точки распространения CRL видны в спецификациях X509v3 сертификата.
Методы определения distinguished name в домене active directory
Вот в общих чертах, что такое Distinguished Name в Active Directory. Материал сайта my-sertif.ru
Подготовка каталогов
Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.
# mkdir /root/ca/intermediate
Создадим точно такую же структуру каталогов, которая используется для корневого центра сертификации. Также удобно создать каталог csr для хранения запросов на подпись сертификатов.
Подготовка конфигурационного файлы
Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert.
Подготовка конфигурационных файлов
Необходимо создать конфигурационный файл для 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 ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.
Подготовка файла конфигурации
Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert.
Подписывание серверного и клиентского сертификатов
Подпишем сертификаты используя наш промежуточный центр сертификации. Эти подписанные сертификаты можно использовать в различных ситуациях, таких как защищать соединения к веб серверу или аутентифицировать клиентов, присоединяющихся к сервису.
Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.
Проверка корневого сертификата
# 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 2021 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
Проверка промежуточного сертификата
Как мы делали с корневым сертификатом, убедимся, что детали промежуточного сертификата корректны.
# 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
Создание 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.
Создание ключа
Наши корневая и промежуточная пары 4096 бит. Серверный и клиентский сертификат обычно истекают после одного года, поэтому мы можем безопасно использовать 2048 бит.
Хотя 4096 бит немного больше безопаснее, чем 2048 бит, он замедляет TLS хэндшейки и значительно увеличивает нагрузку на процессор во время хэндшейков. По этой причине, большинство веб-сайтов используют 2048-битные пары ключей.
Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.
Создание корневого ключа
Создадим корневой ключ (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 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными.
# 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
Создание корневой пары ключей
Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.
Как правило, корневой центр сертификации не подписывает напрямую серверные или клиентские сертификаты. Корневой центр сертификации используется только для создания одного или нескольких промежуточных центров сертификации, которые являются доверенными корневому центру сертификации чтоб подписывать сертификаты от их имени.
Это является лучшей практикой. Таким образом, корневой ключ может хранится «оффлайн» и по-максимому не использоваться, так как любая компрометация губительна для ключа. В качестве примера лучшей практики является создание корневой пары в максимально защищенной среде.
Создание пары ocsp
Ответчик OCSP нуждается в криптографической паре для подписывания ответа, который посылается запрашивающей стороне. Криптографическая пара OCSP должна быть подписана на том же центре сертификации, на котором проверяется подписанный сертификат.
Создадим частный ключ и зашифруем его алгоритмом AES-256.
Создание промежуточного ключа
Создадим промежуточный ключ (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
Создание промежуточной пары ключей
Промежуточным центомр сертификации является объект, который может подписывать сертификаты от имени корневого центра сертификации. Корневой центр сертификации подписывает промежуточный сертификат, образуя цепочку доверия.
Цель использования промежуточного центра сертификации, прежде всего, для обеспечения безопасности. Корневой ключ должен храниться «оффлайн» и использоваться как можно реже. Если промежуточный ключ будет скомпрометирован, корневой центр сертификации может отозвать промежуточный сертификат и создать новую промежуточную криптографическую пару.
Создание файла цепочки сертификатов
Когда приложение (например, веб-браузер) пытается проверить сертификат, подписанный промежуточным центром сертификации, оно также должно проверить промежуточный сертификат от корневого центра сертификации. Для выполнения проверки цепочки доверия создадим цепочку сертификатов центра сертификации для предоставления приложениям.
Чтобы создать цепочку сертификатов требуется объеденить промежуточные и корневые сертификаты вмете. Позже мы будем использовать этот файл для проверки сертификатов подписанных промежуточным центром сертификации.
# cat intermediate/certs/intermediate.cert.pem
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem
Наш файл цепочки сертификатов должен содержать корневой сертификат, потому что клиентские приложения ничего не знают о нем. Лучшим вариантом, особенно, если вы администратор сети, является установка корневого сертификата на каждом клиенте, которому требуется подключаться к приложению.
Статья – проверка электронной цифровой подписи authenticode. часть 1. теория
1.4.1. Что такое Authenticode (Code signing).
“Authenticode” (или «Code signing») означает, что сертификат предназначен для подписания кода, иначе говоря, программ и скриптов, а не документов, электронных писем, http интернет пакетов и тому подобного.
К файлам, содержащим код, относят такие форматы, как PE (.exe, .dll, .ocx, .sys, …), VBScript (.vbs), JScript (.js), Cabinet-архивы (.cab), элементы панели управления (.cpl) и некоторые другие.
Рассмотрим поближе такие понятия как: хеш, алгоритм хеша, подпись, сертификат, отпечаток, выборка и т.п. (часть информации взята из ответов участников конференции StackExchange CBHacking и Tom Leek (в переводе, с авторской переработкой и дополнениями)).
1.4.2. Что такое хеш.
Хеш – это значение фиксированной длины, которое получено после выполнения набора арифметических операции над строкой, файлом или другим блоком данных. Грубо говоря, мы подаём на вход длинную строку, затем берём код каждого символа этой строки, складываем по определённому принципу (называемому алгоритмом хеша), и в результате получаем значение, обычно записываемое в 16-ричном виде.
Вот примеры наиболее распространённых хешей:
Подробную таблицу сравнительных характеристик SHA вы можете посмотреть на wiki
здесь
и
здесь
.
Программно рассчитывать хеш можно, например, через CryptoAPI (пример) или Cryptography API: Next Generation (CNG) (пример).
1.4.3. Что такое выборка (дайджест).
Выборка (digest) – обычно подразумевает, что мы берём данные не целиком, а избирательно, только какую-то часть, которая и называется выборкой. Расположение этой части зависит от структуры данных и вида алгоритма, для которого эта выборка используется.
Например, Authenticode-хеш рассчитывается из всего файла, кроме той его части, где хранится подпись, иначе добавление подписи к файлу автоматически означало бы его повреждение, либо пришлось бы заново перерасчитывать хеш, заменять подпись уже с новым хешем, снова перерасчитывать хеш и так до бесконечности, что само собой невозможно.
1.4.4. Что такое приватный и публичный ключи, симметричное и асимметричное шифрование.
Представьте себе шифрование по алгоритму Цезаря, где код каждого символа строки сдвигается на некоторое одинаковое количество пунктов (например, вперёд по алфавиту). Здесь ключом является – количество пунктов сдвига.
Зная алгоритм и ключ, вы можете расшифровать такое сообщение.
Этот алгоритм называется симметричным, потому что один и тот же ключ используется и для шифрования, и для расшифровки.
Существуют и так называемые асимметричные алгоритмы, например, RSA. Здесь ключи для шифрования и дешифровки – разные. Т.е. ключ шифрования не подходит для расшифровки, и наоборот. Кроме того, невозможно рассчитать ключ шифрования, если у вас есть ключ дешифровки.
Представьте, что вам дали сообщение, зашифрованное ключом (он называется – приватный). Вы знаете, по какому принципу происходит шифрование, и у вас даже есть ключ (публичный), которым можно расшифровать сообщение. Но с помощью этого же ключа у Вас не получится снова зашифровать исходное сообщение, чтобы получить такую же шифро-фразу, потому как результат уже не расшифруется тем же ключом. Такова особенность асимметричных алгоритмов. Подробнее о них вы можете почитать в протоколе Диффи-Хеллмана-Меркла или посмотреть это видео:
Приватный ключ ещё называют закрытым (или секретным).
Публичный ключ также называют открытым и обычно свободно распространяют.
Поскольку алгоритм RSA весьма медленный, зачастую им не шифруют всё сообщение. Вместо этого используется один из симметричных алгоритмов, а RSA накладывают на сам ключ, использованный на первом этапе – в симметричном шифровании.
В контексте подписания и проверки цифровых подписей шифрование всего сообщение не нужно и не требуется. Вместо этого, RSA накладывается на хеш сообщения.
Итоговая схема:
ФАЙЛ => выборка => хеш приватный ключ => шифрованный хеш.
1.4.5. Что такое сертификат, центр сертификации и цепочка доверия.
Сертификат связывает личность (издателя) с публичным ключом (который где-то имеет соответствующий приватный ключ). Сперва вы признаёте, что сертификат действителен – то есть содержащийся в нём ключ действительно принадлежит лицу или организации, которое он идентифицирует. Для защиты от подделки сертификаты также подписываются цифровой подписью.
Центр сертификации – это объект (обычно, организация), которой доверено выдавать сертификаты, утверждающие, что индивидуальный получатель, компьютер или организация, запрашивающие сертификат, выполняют условия установленной политики (подробнее: см. раздел 1.10 «Покупка сертификата»). Под политикой здесь обычно подразумевают, что центр сертификации подтвердил подлинность предоставленных получателем документов, которые его идентифицируют (имя, место проживания и т.п.).
Сертификат может быть подписан не напрямую центром сертификации, а промежуточным звеном, которому Центр предоставил права выдавать сертификаты. Это называется цепочкой доверия. Её можно проследить, изучив цифровую подпись сертификата:
Сертификат считается легитимным, если он подписан (закрытым) ключом, соответствующим (публичному ключу) сертификата, которому вы доверяете. Соответственно, в цепочке доверия к самому первому (корневому) сертификату звена у вас должны быть установлены отношения доверия (в контексте исполняемых файлов Windows это означает, что такой сертификат должен быть помещён в корневое хранилище – см. подробнее далее в разделе 1.5.).
1.4.6. Форматы файлов сертификатов и ключей для Authenticode подписи и их преобразование.
а) Виды форматов.
Важным моментом с точки зрения безопасности является тот факт, что разные форматы сертификатов могут хранить только приватный ключ, только публичный, или оба из них.
PKCS # 12 и PKCS # 7
– это международные спецификации криптографии с открытым ключом.
Формат X.509 (его ещё называют сертификатом открытого ключа). Он состоит из таких частей:
Внутри каждого сертификата формата X.509 хранится пара Distinguished Names (DN) в формате X.500. Один DN принадлежит владельцу сертификата, а второй DN указывает идентификатор CA, подписавшей сертификат. В случае с self-signed сертификатом, оба эти DN указывают на владельца сертификата.
Distinguished Name задается в виде разделенных через запятую атрибутов, например:
Здесь отдельные атрибуты расшифровываются так:
CN — common name (уникальное имя владельца)
L — localityName (местоположение: город)
ST — stateOrProvinceName (название штата или провинции)
O — organizationName (имя организации)
OU — organizationUnit, department or division (департамент или отдел)
C — country, two-letter country code (двухбуквенный код страны)
STREET = streetAddress (адрес: улица)
DC = domainComponent (метка доменного имени)
UID = userid (идентификатор пользователя)
Часть из атрибутов может быть пропущено, например, присвоено значение Unknown.
Формат строки описан в RFC2253 и RFC1779.
Подробнее о внутренней структуре формата сертификата X.509 можно почитать в статьях:
X.509 — Википедия
Разбираем x.509 сертификат
Структура PKCS7-файла
RFC5280
Microsoft PVK – является недокументированным форматом, однако кое-что о его структуре можно почитать в этой заметке:
PVK file format
Примечательно, что на этапе генерации пары ключей, вам необходимо будет ввести пароль. Это дополнительная мера защиты. Приватный ключ шифруется одним из алгоритмов – 3DES, RC4 или RC2. Без знания пароля потенциальный злоумышленник, выкравший файл сертификата, не сможет воспользоваться приватным ключом.
б) Преобразование форматов.
Иногда возникает необходимость сконвертировать форматы сертификатов из одного в другой. Для этих целей вам могут пригодиться такие инструменты из состава Windows SDK, как pvk2pfx.exe, cert2spc.exe, а также openssl.
Примеры конвертации:
Некоторые другие примеры командной строки преобразования форматов можно посмотреть в
этой базе знаний Symantec
.
Выше рассмотрены только сертификаты для подписания кода. Так, следует заметить, что например, для SSL-сертификатов существуют и другие форматы, например, .jks – Java Key Stroke – это хранилище открытых и закрытых ключей и сертификатов. Работать с ним можно с помощью инструмента keytool из состава Java Runtime Environment.
Пример для JKS -> DER см. в моей заметке: Как получить ЭЦП для подписания документов (для жителей Украины).
Вот ещё часть примеров для демонстрации возможностей openssl (взято отсюда):
Установка сертификата
Теперь можно установить новый сертификат на сервере, или распространить сертификат на клиентов. При установке на серверное приложение (к примеру, Apache), понадобятся следующие файлы:
Списки отзывов сертификатов
Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.
Отзыв сертификата
Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.
Создадим серверный сертификат для тестирования.