Конвертация сертификата в форматы pkcs12/pfx/p12 – RU-CENTER

Что происходит на практике

1. Client Hello – клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.

   Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA – Риверт-Шамир-Адлеман, DH – Диффи-Хеллмана, ECDH – Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES – Advanced Encryption Standard, 3DES – Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 – Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).

   Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.

2. Server Hello – сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.

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

3. Certificate – сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.

   Что представляет из себя сертификат? Сертификат – это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.

   Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, – вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.

   Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA – Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом – это цепочка подписания.

   Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).

4. Server Key Exchange – этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Y_s=g^{случайно выбранное сервером число}mod p, где mod – это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Y_c=g^{случайно выбранное клиентом число}mod p. После этого сервер считает Y_c^{случайно выбранное сервером число}mod p, а клиент Y_s^{случайно выбранное клиентом число}mod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:

5. Server Hello Done – сервер сообщает, что начальный этап установки соединения завершен

6. Client Key Exchange – как было уже сказано выше, когда сервер передал числа p, g, Y_s в Server Key Echange, клиент передает свое число Y_c в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret – предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.

7. Change Cipher Spec – клиент говорит серверу, что он готов перейти на защищенное соединение.

8. Finished – клиент зашифровывает симметричным ключом первое сообщение с MAC.

9. Change Cipher Spec – сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.

10. Finished – аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение

11. После этого соединение считается установленным, и происходит передача полезной информации

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

Tlsv1.3

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

Выполним операции по pkcs #12

Создадим архив PKCS #12, используя

samplepassword 

в качестве пароля.

$ openssl pkcs12 -export -name example.org -in example.org.pem -inkey example.org.key -out example.org.p12 -password pass:samplepassword

Выведем информацию о файле PKCS# 12 для простой проверки.

Введите пароль с помощью командной строки.

$ openssl pkcs12 -in example.org.p12  -info -password pass:samplepassword -noout
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем “password” длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096

Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте “CN=Certificate authority” (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password – все поля, кроме CN опциональны), приватный ключ и пароль от него:

openssl req -new -key CA-private-key.key -passin pass:password -subj "/CN=Certificate authority/" -out CA-certificate-signing-request.csr t $3

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key.key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE

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

openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj "/CN=localhost/" -out Server-certificate-signing-request.csrt $3

openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj "/CN=Client/" -out Client-certificate-signing-request.csr

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

openssl x509 -req -in Server-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем “password”:

openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12      

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt    

Для удобства, все описанные выше действия упакованы в bash script.

Двусторонний tls

Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.

Как создать образец сертификата.

$ openssl req -subj "/commonName=example.org/" -x509 -nodes -days 730 -newkey rsa:2048 -keyout example.org.key -out example.org.pem

-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgIUY5YmshFi3LCcZ4659dQ90IUpMX0wDQYJKoZIhvcNAQEL
BQAwFjEUMBIGA1UEAwwLZXhhbXBsZS5vcmcwHhcNMjAwMTE0MDAwMDExWhcNMjIw
MTEzMDAwMDExWjAWMRQwEgYDVQQDDAtleGFtcGxlLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANWClj4Jn7D4MUHMjZUcY/dx3RroU tPgEkUjxJU
P9srhkDWKIVFqzZDfFldHg3KWQWvbmHVhWGobQY6ylx5epFy62nAXMvkfkiPefne
6A6XxOomhJ71E4VeSNiY50vbRxzOOwKb P 3gtK7KauRK42cP7xjGEQlpVTFOvjl
wGmbUhZxZqS1jpjc6GMkaCIl8 oJD9kCzBjTLBLs rw4DlFndfxim22HEbRClE48
/6eJ0AY9eZzkpuAaPTjYvqIaw s/QWAZTJ 0Ev5YKw5PgPnb7qDPb0hbIcnG2F6/
3Gn3GR6lVrhWjlB1fGxEFDoP8BoGIBafPf8xUlfDyRTZQxcCAwEAAaNTMFEwHQYD
VR0OBBYEFHJPh7s99IvIYjWZCsiOmEOpbEaYMB8GA1UdIwQYMBaAFHJPh7s99IvI
YjWZCsiOmEOpbEaYMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
AIHsx0NMJ7AgyZF/pSlG2dNhxm79K9qdDB adXkdPpQzzIpGAPprU392SVjTYKtZ
S9Y4ELrL G/XwANLWp6UzeMZXsQfUf23LifIrvhHgjtQt/OfRIdlWjWdVOaFHg8T
TZPYcHUHv836evf/2lfLbj2eZIBXoXjfOi pDlxM/h1avrSgS25FG9Qz8PnK8xJ2
85r2xseSYxfhTEzb N8f8RmTdClWwTT6TdeyDaQ0xwdp0W2xWKTCAkgwFyAxAcmk
5n37C8eNZWSrLQEk8i35/ziC2mpgQrNNuxGoG2U8h2RC/e5OZXgxkTqao6ul82Yt
CUVAgzzpIshyiy/VrSjVKoM=
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDVgpY CZ w DFB
zI2VHGP3cd0a6FPrT4BJFI8SVD/bK4ZA1iiFRas2Q3xZXR4NylkFr25h1YVhqG0G
OspceXqRcutpwFzL5H5Ij3n53ugOl8TqJoSe9ROFXkjYmOdL20cczjsCm/j/t4LS
uymrkSuNnD 8YxhEJaVUxTr45cBpm1IWcWaktY6Y3OhjJGgiJfPqCQ/ZAswY0ywS
7Pq8OA5RZ3X8YptthxG0QpROPP nidAGPXmc5KbgGj042L6iGsPrP0FgGUyftBL 
WCsOT4D52 6gz29IWyHJxthev9xp9xkepVa4Vo5QdXxsRBQ6D/AaBiAWnz3/MVJX
w8kU2UMXAgMBAAECggEAGq6NFAej2zvI/A4SC3ZWz8988CXkht2SjI9zKbk5mawg
xO1 dtk0Aj4AxjIq1VJaOamow7UpTAD Tu795vyPYqnX3Ylaj2hol6zGc4F1wo0Y
4KIbpLm/zMTxmY/SJ9qpUmI7YaIYReyq/qbBGF218aZ7GJHRsIJ73NIhAoXDu 6g
fWjRg19hSz/EM/68hPxM7vstPC0S/zdMicrnbcCtA23AJL5cyifa1W1VkMv3SW3t
fswSvxLT4qDRyBxc6Xq0ULNm1Q FMyhqtPhnUX4qi9289cal0U 9rfEhFc2q0I2T
VujPz76Ncm4IGeh/lf67dHYvwy7qHaPmL3Wto1U0IQKBgQD9hMjS6k8pkz7WCLJl
0JNHw0QWczM5 q2BfQM7w8McmWX0mvKqkLiGLyIo1QS8GgR uOoEJ8v5rNZLW1SU
Q4SWExj8IQL ofUDn4U1zbKtyRXybURC0GWGjbX8F4YJrLBmAuCeJNB6If4RTT/T
q9ZFYPwRzjOO QZMICKDZlIriQKBgQDXmY6auU8uPSkPbCuZzUPX3z fVVwRg8mm
zPGlsZ uQvQT9qU37RpoWKxMRjjS61F2qdyxr6   LqmAVU/QSdokJQP2A0LVCeG
 zPY/6zj4Y7CI81T2r9P6eVBVhS7eg9ggrnyIqwdBykh u0zKXDSkfp7hEoChvL0
G6Cc2 MxnwKBgAwii/5Uit BldNm7SskdbhMp3ivoPcYga eDUaSE0fOK wucokp
jjuWC/uKXsSmNirerQzv3rqfxE4tG/pQ1Qrd9Sc0aVFI7VJ0E0tFAlWBN5S4GDle
gk2TgO FLLxP0M3BO4E2X hIskGfwfte0U3W25n6lcs1LlD8hMpnXm2JAoGBAJAu
zUOD8gQGOtNpj68HqvtO/Ylc2HmOHOlD3cblhthPRlOjetJv6l0mD/PiclX7sTse
Vc0upOWeCZTDB3OJ6wTuy1XdMrwEx3ppvD6 nay4R3Rl5QbTH2YeEYckPjEya94r
DpdzwI6ZH1TuLnssl5r6rPy1d5lBDnFZmIvOMZ4ZAoGAL9m3qzKmOlqGAD32w11V
0zzr0orZPRiCXZ1SqQ1MRwKUexZeDCee4ZVZhhPtlyk8btqgG4j85RffFHbcwuv3
eGgx6S/6GzXRu0sICLrAmHT Q2WA/PKp0kD6Abz1DXLJUjr/nF6UUkqEOrCvGXoq
2MhMYc07op riO 4pUwfzRY=
-----END PRIVATE KEY-----

$ openssl pkcs12 -export -name example.org -in example.org.pem -inkey example.org.key -out example.org.p12 -password pass:samplepassword

$ openssl pkcs12 -in example.org.p12  -info -password pass:samplepassword -noout
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

Конвертация pem в der

Для конвертации стандартного сертификата в формате PEM в бинарный формат DER, потребуется только файл SSL сертификата. Обычно, вы его получаете в архиве вместе с промежуточными сертификатами. Как правило, в его названии указано имя вашего домена.

Конвертация pem в p7b / pkcs#7

Если же вам нужно преобразовать ваш стандартный SSL сертификат в файл формата P7B / PKCS#7, вы можете кроме SSL сертификата вашего домена загрузить также файлы с цепочками сертификатов.

Конвертация pem в pfx / pkcs#12

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

Приватный ключ создается в момент генерации CSR запроса. Если вы генерируете CSR у себя на сервере, на нем же должен автоматически сохраниться ключ. Если вы создаете CSR запрос в специальном инструменте на нашем сайте (на странице по ссылке или во время заполнения технических данных), ключ показывается вам в конце генерации CSR (или введения технических данных), но не сохраняется в нашей базе данных. Поэтому важно, чтобы вы самостоятельно сохранили приватный ключ.

Конвертация ssl сертификатов посредством openssl

OpenSSL — это надежный, коммерческий и полнофункциональный инструментарий для протоколов Transport Layer Security (TLS) и Secure Sockets Layer (SSL). А также библиотека криптографии общего назначения. Конвертация с использованием библиотеки OpenSSL считается одним из самых безопасных способов: все данные будет сохранены непосредственно на устройстве, на котором будут выполняться операции по конвертированию.

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

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

Конвертировать PEM в DER можно посредством команды:

openssl x509 -outform der -in site.crt -out site.der

Аналогично, для других типов:

PEM в P7B

openssl crl2pkcs7 -nocrl -certfile site.crt -out site.p7b -certfile site.ca-bundle

PEM в PFX

openssl pkcs12 -export -out site.pfx -inkey site.key -in site.crt -certfile site.ca-bundle

Обращаем ваше внимание, что после выполнения команды, будет запрошена установка пароля ключа.

DER в PEM

openssl x509 -inform der -in site.der -out site.crt

P7B в PEM

openssl pkcs7 -print_certs -in site.p7b -out site.cer

P7B в PFX

openssl pkcs7 -print_certs -in site.p7b -out certificate.ceropenssl pkcs12 -export -in site.cer -inkey site.key -out site.pfx -certfile site.ca-bundle

PFX в PEM

openssl pkcs12 -in site.pfx -out site.crt -nodes

Конвертация сертификата в форматы pkcs12/pfx/p12 – ru-center

Конвертация скриптом openssl-toolkit

OpenSSL ToolKit — скрипт, который облегчает работу с библиотекой OpenSSL. Работа со скриптом является безопасным решением, т.к сертификаты и ключи сертификата никуда не передаются, а используются  непосредственно на вашем сервере.

Ответ 2

PEM – сам по себе не является сертификатом, это просто способ кодирования данных. Сертификаты X.509 – это один из типов данных, которые обычно кодируются с помощью PEM.

PEM – это сертификат X.509 (структура которого определена с помощью ASN.1), закодированный с помощью ASN.1 DER (distinguished encoding rules),  затем закодированный Base64 кодировкой и вставленный между заголовками текста (BEGIN CERTIFICATE и END CERTIFICATE).

Вы можете представить те же данные, используя представления PKCS#7 или PKCS#12, и для этого можно использовать утилиту командной строки OpenSSL.

Очевидным преимуществом PEM является то, что его безопасно вставлять в тело электронного сообщения, поскольку он имеет заголовки и 7-битную кодировку.

RFC1422 содержит более подробную информацию о стандарте PEM в части, касающейся ключей и сертификатов. 

Способы конвертации

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

Форматы сертификатов

Существует четыре основных формата сертификатов:

PEM — популярный формат используемый Центрами Сертификации для выписки SSL-сертификатов.

Основные расширения этого типа .pem, .crt, .cer, .key. В файлах содержатся строки вида

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY ------

Сертификаты PEM подходят для установки на веб-серверы nginx, apache2.

DER — это бинарная форма сертификата PEM.

Основные расширения этого типа  сертификата .der .cer

Сертификаты DER подходят для установки на серверы Java.

P7B. Файлы P7B кодируются в формате Base64 и имеют расширение .p7b или .p7c.

В файлах содержатся строки вида

-----BEGIN PKCS7-----
-----END PKCS7-----

Сертификаты P7B подходят для установки на серверы MS Windows, Java Tomcat

PFX — это сертификат в бинарном формате, выданный для домена, включающий в себя сертификат, цепочку сертификатов (корневые сертификаты) и приватный ключ. Имеют расширение .pfx или .p12.

Сертификаты PFX подходят для установки на серверы Windows, в частности Internet Information Services(IIS).

Итоги

В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!