How to convert SSL certificate format using OpenSSL(For Omada SDN Controller)

The most common SSL certificates are defined by X.509. The digital certificates have different formats. Here’s a brief overview of several common formats of SSL certificates:

PEM: private key or certificate

CER: only certificate

DER: only certificate

CRT: only certificate

PFX: private key and certificate

P12: private key and certificate

JKS: private key and certificate

KEY: public key or private key

Omada Controller v5.0.30 or below supports SSL certificate in PFX and JKS format, which contains private key and certificate in one file. If the SSL certificate providers provides us with certificates in other formats, we can use OpenSSL(https://www.openssl.org/) to convert private key and certificate to PEM format at first, and then convert PEM certificate to PFX certificate.

Omada Controller v5. 1 already supports PEM certificate, so we don’t need to convert PEM certificate to PFX/JKS certificate.

Following are the commands to convert certificate and private key to PFX format in OpenSSL.

1. Convert certificate and private key in PEM format to PFX format.

Openssl pkcs12 -export -out certificate.pfx -inkey privkey.pem -in cert.pem

Note: Export Password is the “Keystore Password” in Omada Controller.

privkey.pem is the private key in PEM format.

cert.pem is the certificate in PEM format.

certificate.pfx is the SSL certificate in PFX format.

2. Convert certificate in CRT, DER or CER format to PEM format.

openssl x509 -in cert.crt -out cert.pem -outform PEM

cert.crt is the certificate in CRT format. We also can replace it with certificate in DER or CER format.

cert.pem is the certificate in PEM format.

3. Convert private key in KEY format to PEM format.

openssl rsa -in private. key -out private.pem -outform PEM

Note: pass phrase is the password of private key.

private.key is the private key in KEY format.

Private.pem is the private key in PEM format.

Был ли этот FAQ полезен?

Ваш отзыв поможет нам улучшить работу сайта.

Что вам не понравилось в этой статье?

  • Недоволен продуктом
  • Слишком сложно
  • Неверный заголовок
  • Не относится к моей проблеме
  • Слишком туманное объяснение
  • Другое

Как мы можем это улучшить?

Спасибо

Спасибо за обращение
Нажмите здесь, чтобы связаться с технической поддержкой TP-Link.

Использование OpenSSL: хеши, цифровые подписи и многое другое : Rebrain

Visitors have accessed this post 7791 times.

Перевод статьи — https://opensource.com/article/19/6/cryptography-basics-openssl-part-2

Детальный обзор шифрования в OpenSSL: хеши, цифровые подписи, цифровые сертификаты и многое другое

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

Криптографические хеши

Страница загрузки исходного кода OpenSSL (https://www.openssl.org/source/) содержит таблицу с последними версиями. Каждая версия имеет два значения хеш-функции: 160-bit SHA1 и 256-bit SHA256. Эти значения можно использовать для проверки соответствия загруженного файла оригиналу в репозитории: загрузчик пересчитывает значения хеш-функции локально в загруженном файле, а затем сравнивает результаты с оригиналами. Современные системы уже имеют встроенные утилиты для вычисления подобных хешей. Операционная система Linux, например, имеет хеши

md5sum и sha256sum. В OpenSSL предусмотрены аналогичные утилиты командной строки.

Хеши используются во многих областях вычислений. Например, блокчейн биткойнов использует хеш-значения SHA256 в качестве идентификаторов блоков. Чтобы майнить биткойн, необходимо сгенерировать хеш-значение SHA256, которое падает ниже заданного порога, то есть, хеш-значение как минимум с начальными нулями N. (Значение N может увеличиваться или уменьшаться в зависимости от того, насколько продуктивен майнинг в конкретное время). Интересно, что современные майнеры представляют собой аппаратные кластеры, предназначенные для параллельной генерации хешей SHA256. Во время пикового периода в 2018 году майнеры биткойнов по всему миру генерировали около 75 миллионов терахешей в секунду — еще одно непостижимое число.

Сетевые протоколы также используют хеш-значения — часто под именем контрольной суммы — для поддержки целостности сообщения; то есть, чтобы убедиться, что полученное сообщение совпадает с отправленным. Отправитель сообщения вычисляет контрольную сумму сообщения и отправляет результаты вместе с сообщением. Получатель пересчитывает контрольную сумму при получении сообщения. Если отправленная и пересчитанная контрольная сумма не совпадают, то что-то случилось с сообщением при передаче, либо с отправленной контрольной суммой, либо с обеими. В этом случае сообщение и его контрольную сумму следует отправить повторно или, по крайней мере, создать условие ошибки. (Сетевые протоколы низкого уровня, такие как UDP, не запариваются насчет контрольных сумм).

Другие примеры хешей более или менее известны. Рассмотрим веб-сайт, требующий от пользователей аутентификации с паролем, который пользователь вводит в своем браузере. Пароль затем отправляется в зашифрованном виде из браузера на сервер через HTTPS-соединение с сервером. Когда пароль поступает на сервер, он дешифруется для поиска в базе данных по таблице.

Что должно храниться в этой таблице поиска? Хранить одни пароли — рискованное дело.

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

Хеш-значения также встречаются в различных сферах безопасности. Например, код аутентификации сообщений на основе хеша (HMAC) использует значение хеш-функции и секретный криптографический ключ для аутентификации сообщения, отправленного по сети. Коды HMAC, которые так легки и просты в использовании в программах, популярны и в веб-сервисах. Цифровой сертификат X509 включает в себя значение хеш-функции, известное как

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

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

chf в качестве криптографической хеш-функции и паролем foobar в качестве примера ввода:

       +---+

foobar—>|chf|—>хеш-значение ## прямолинейное

        +--–+

Для сравнения, обратная операция является невозможной:

          +-----------+

хеш-значение—>|chf inverse|—>foobar ## труднорешаемое

            +-----------+

Вспомните, например, хеш-функцию SHA256. Для входной строки битов любой длины N> 0 эта функция генерирует хеш-значение фиксированной длины, равное 256 битам; следовательно, это значение хеша не показывает даже длину N входной строки битов, не говоря уже о значении каждого бита в строке. Кстати, SHA256 не подвержен атаке удлинением сообщения. Единственный эффективный способ обратного инжиниринга вычисленного значения хеш-функции SHA256 обратно во входную строку битов — это поиск методом последовательного перебора, то есть, перебор каждой возможной входной строки битов, пока не будет найдено совпадение с целевым значением хеш-функции. Такой поиск невозможен с использованием криптографической хеш-функции SHA256.

Теперь финальная точка обзора в порядке. Криптографические хеш-значения статистически, но не безусловно уникальны, а это означает, что две разные входные строки битов вряд ли, но возможно, выдают одно и то же хеш-значение — коллизию. Парадокс дней рождения представляет собой довольно противоречивый пример коллизий. Существует обширное исследование устойчивости к коллизиям различных хеш-алгоритмов. Например, MD5 (128-битные значения хеша) имеет разбивку в сопротивлении коллизии после примерно 221 хеша. Для SHA1 (160-битные значения хеша) разбивка начинается примерно с 261 хеша.

Пока что нет точной оценки пробоя в сопротивлении коллизии для SHA256. И это не удивительно. SHA256 имеет диапазон 2256 различных значений хеша, число, десятичное представление которого имеет 78 цифр! Бывают ли коллизии с хешированием SHA256? Конечно, но они крайне маловероятны.
В следующих примерах командной строки в качестве источников строк битов используются два входных файла: hashIn1.txt и hashIn2.txt. Первый файл содержит значения abc, а второй — 1a2b3c.

Для удобства чтения файл содержит текст, но вместо этого можно использовать двоичные файлы.
Используя утилиту Linux sha256sum для этих двух файлов в командной строке — со знаком процента (%) в качестве приглашения, можно создать следующие значения хеша (в шестнадцатеричной форме):

% sha256sum hashIn1.txt

9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3 hashIn1.txt

% sha256sum hashIn2.txt

3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13 hashIn2. txt

Как и ожидалось, хешированные аналоги OpenSSL дают те же результаты:

% openssl dgst -sha256 hashIn1.txt

SHA256(hashIn1.txt)= 9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3

% openssl dgst -sha256 hashIn2.txt

SHA256(hashIn2.txt)= 3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13

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

Цифровые подписи

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

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

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

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

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

Теперь рассмотрим на примере. Для начала сгенерируем 2048-битную пару ключей RSA с OpenSSL:

openssl genpkey -out privkey.pem -algorithm rsa 2048

В этом примере мы можем убрать флаг -algorithm rsa, поскольку по умолчанию genpkey имеет тип RSA. Имя файла (privkey.pem) является произвольным, но расширение pem Privacy Enhanced Mail (PEM) является стандартным для формата PEM по умолчанию. (Если необходимо, в OpenSSL есть команды для преобразования между форматами. ) Если требуется больший размер ключа (например, 4096), то последний аргумент 2048 можно изменить на 4096. Эти размеры всегда имеют степень двойки.
Вот фрагмент получившегося файла privkey.pem, который находится в base64:

-----BEGIN PRIVATE KEY-----

MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBANnlAh5jSKgcNj/Z

JF4J4WdhkljP2R+TXVGuKVRtPkGAiLWE4BDbgsyKVLfs2EdjKL1U+/qtfhYsqhkK

…

-----END PRIVATE KEY-----

Следующая команда затем извлекает открытый ключ пары из закрытого:

openssl rsa -in privkey.pem -outform PEM -pubout -out pubkey.pem

Полученный файл pubkey.pem небольшой, поэтому его можно отобразить в полном виде:

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZ5QIeI0ioHDY/2SReCeFnYZJY

z9kfk11RrilUbT5BgIi1hOAQ24LMilS37NhHYyi9VPv6rX4WLKoZCmkeYaWk/TR5

4nbh2E/AkniwRoXpeh5VncwWMuMsL5qPWGY8fuuTE27GhwqBiKQGBOmU+MYlZonO

O0xnAKpAvysMy7G7qQIDAQAB

-----END PUBLIC KEY-----

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

openssl dgst -sha256 -sign privkey.pem -out sign.sha256 client.c

Дайджестом для исходного файла client.c является хеш-функция SHA256, а закрытый ключ находится в ранее созданном файле privkey.pem. Полученный файл двоичной подписи — это sign.sha256, то есть, произвольное имя. Чтобы получить читабельную (с помощью base64) версию этого файла, выполните следующую команду:

openssl enc -base64 -in sign.sha256 -out sign.sha256.base64

Файл sign.sha256.base64 теперь содержит:

h+e+3UPx++KKSlWKIk34fQ1g91XKHOGFRmjc0ZHPEyyjP6/lJ05SfjpAJxAPm075

VNfFwysvqRGmL0jkp/TTdwnDTwt756Ej4X3OwAVeYM7i5DCcjVsQf5+h7JycHKlM

o/Jd3kUIWUkZ8+Lk0ZwzNzhKJu6LM5KWtL+MhJ2DpVc=

Или же, вместо этого, можно подписать исполняемый файл-клиент, но при этом, полученная подпись в кодировке base64 естественно будет отличаться:

VMVImPgVLKHxVBapJ8DgLNJUKb98GbXgehRPD8o0ImADhLqlEKVy0HKRm/51m9IX

xRAN7DoL4Q3uuVmWWi749Vampong/uT5qjgVNTnRt9jON112fzchgEoMb8CHNsCT

XIMdyaPtnJZdLALw6rwMM55MoLamSc6M/MV1OrJnk/g=

Заключительный этап в этом процессе — это проверка цифровой подписи с открытым ключом. Хеш, используемый для подписи артефакта (в данном случае исполняемой программой-клиентом), должен быть пересчитан как важный этап проверки, поскольку процесс проверки должен указывать, изменился ли артефакт с момента подписания.

Для этого используются две команды OpenSSL. Первый расшифровывает подпись base64:

openssl enc -base64 -d -in sign.sha256.base64 -out sign.sha256

Второй проверяет подпись:

openssl dgst -sha256 -verify pubkey.pem -signature sign.sha256 client

Вывод второй команды должен показать результат:

Verified OK

Чтобы понять, что происходит при сбое проверки, существует краткое, но полезное упражнение, суть которого заменить исполняемый файл клиента в последней команде OpenSSL исходным файлом client.c, а затем выполнить проверку. Другое упражнение состоит в том, чтобы немного изменить программу-клиент и повторить попытку.

Цифровые сертификаты

Цифровой сертификат объединяет фрагменты, проанализированные до настоящего момента: хеш-значения, пары ключей, цифровые подписи и шифрование/дешифрование. Первым этапом на пути к получению сертификата производственного уровня является создание запроса на подпись сертификата (CSR), который затем отправляется в центр сертификации (CA). Чтобы сделать это с помощью OpenSSL, запустите:

openssl req -out myserver.csr -new -newkey rsa:4096 -nodes -keyout myserverkey.pem

В этом примере создается документ CSR и сохраняется документ в файле myserver.csr (текст base64). Для чего это нужно: документ CSR отправляет запрос, чтобы ценрт сертификации поручился за его идентичность с указанным доменным именем — общим именем (CN) в CA.

Новая пара ключей также генерируется этой командой, хотя можно использовать уже существующую пару. Обратите внимание, что использование сервера в именах myserver.csr и myserverkey. pem, указывает на типичное использование цифровых сертификатов: в качестве поручителей идентификации веб-сервера, связанного с доменом как, например, www.google.com.

Однако эта же команда создает CSR независимо от способа использования цифрового сертификата. Она точно также запускает интерактивный сеанс вопросов/ответов, который запрашивает соответствующую информацию о доменном имени для связи с цифровым сертификатом запрашивающей стороны. Этот интерактивный сеанс может прерваться путем предоставления основ в рамках команды с обратными слешами в качестве продолжения через разрывы строк. Флаг -subj вводит необходимую информацию:

% openssl req -new

-newkey rsa:2048 -nodes -keyout privkeyDC.pem

-out myserver.csr

-subj "/C=US/ST=Illinois/L=Chicago/O=Faulty Consulting/OU=IT/CN=myserver.com"

Полученный документ CSR может быть проверен перед отправкой в CA. Этот процесс создает цифровой сертификат с желаемым форматом (например, X509), подписью, датами действия и т. д.

openssl req -text -in myserver.csr -noout -verify

Вот фрагмент вывода:

verify OK

Certificate Request:

Data:

Version: 0 (0x0)

Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73:

…

Exponent: 65537 (0x10001)

Attributes:

a0:00

Signature Algorithm: sha256WithRSAEncryption

…

Самостоятельно сгенерированный сертификат

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

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout myserver.pem -out myserver.crt

Ниже приводится читабельная версия сгенерированного сертификата через команду OpenSSL:

openssl x509 -in myserver.crt -text -noout

Вот фрагмент вывода самостоятельно сгенерированного сертификата:

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 13951598013130016090 (0xc19e087965a9055a)

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com

Validity

Not Before: Apr 11 17:22:18 2019 GMT

Not After : Apr 10 17:22:18 2020 GMT

Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver. com

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (4096 bit)

Modulus:

00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73:

…

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier:

3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91

X509v3 Authority Key Identifier:

keyid:3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91




        X509v3 Basic Constraints:

            CA:TRUE

Signature Algorithm: sha256WithRSAEncryption

     3a:eb:8d:09:53:3b:5c:2e:48:ed:14:ce:f9:20:01:4e:90:c9:

     …

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

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

  • Цифровой сертификат содержит показатели степени и модуля, которые составляют открытый ключ. Эти значения являются частью пары ключей в первоначально сгенерированном файле PEM, в данном случае в файле myserver.pem.
  • Показатель степени почти всегда равен 65 537 (как в этом случае), и поэтому его можно игнорировать.
  • Модуль из пары ключей должен совпадать с модулем из цифрового сертификата.

Модуль — это большое значение, которое может быть хешировано для удобства прочтения. Ниже приведены две команды OpenSSL, которые проверяют один и тот же модуль, тем самым подтверждая, что цифровой сертификат основан на паре ключей в файле PEM:

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 13951598013130016090 (0xc19e087965a9055a)

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.com

Validity

Not Before: Apr 11 17:22:18 2019 GMT

Not After : Apr 10 17:22:18 2020 GMT

Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver. com

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (4096 bit)

Modulus:

00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73:

…

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier:

3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91

X509v3 Authority Key Identifier:

keyid:3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91




        X509v3 Basic Constraints:

            CA:TRUE

Signature Algorithm: sha256WithRSAEncryption

     3a:eb:8d:09:53:3b:5c:2e:48:ed:14:ce:f9:20:01:4e:90:c9:

     …

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

Возвращаемся к вопросу распространения ключей


Давайте вернемся к вопросу, затронутому в конце 1 статьи: согласование TLS между программой-клиентом и веб-сервером Google. Существуют различные протоколы согласования, и даже версия протокола Диффи-Хеллмана в работе на примере клиента предлагает возможность для различных манипуляций. Тем не менее, пример клиента следует общему шаблону.Для начала во время согласования TLS, программа-клиент и веб-сервер согласовывают набор шифров, который состоит из используемых алгоритмов. В данном случае, набор включает: ECDHE-RSA-AES128-GCM-SHA256.Сейчас нас интересуют два элемента: алгоритм пары ключей RSA и блочный шифр AES128, используемый для шифрования и дешифрования сообщений в случае успешного установления связи. Что касается шифрования/дешифрования, этот процесс имеет два варианта: симметричный и асимметричный. В симметричном варианте один и тот же ключ используется для шифрования и дешифрования, что в первую очередь поднимает вопрос распространения ключей: как безопасно распространять ключ для обеих сторон? В асимметричном варианте один ключ используется для шифрования (в данном случае открытый ключ RSA), а другой ключ используется для расшифровывания (в данном случае закрытый ключ RSA из той же пары). Программа-клиент имеет открытый ключ веб-сервера Google из сертификата аутентификации, а веб-сервер имеет закрытый ключ из той же пары. Соответственно, программа-клиент может отправлять зашифрованное сообщение на веб-сервер, который сам по себе может легко расшифровать это сообщение.В ситуации с протоколом TLS, симметричный подход имеет два существенных преимущества:

  • Во взаимодействии между программой-клиентом и веб-сервером Google аутентификация является односторонней. Веб-сервер Google отправляет три сертификата программе-клиенту, но сама она не отправляет сертификат веб-серверу; следовательно, веб-сервер не имеет открытого ключа от клиента и не может зашифровать сообщения для клиента.
  • Симметричное шифрование/дешифрование с помощью AES128 почти в тысячу раз быстрее, чем асимметричное с использованием ключей RSA.

Согласование TLS разумно сочетает в себе два вида шифрования/дешифрования. Во время согласования, программа-клиент генерирует случайные биты, называемые секретом (pre-master secret (PMS)). Затем программа-клиент шифрует PMS с помощью открытого ключа сервера и отправляет зашифрованный PMS на сервер, который, в свою очередь, дешифрует сообщение PMS своим закрытым ключом из пары RSA:

              +-------------------+ зашифрованныйPMS  +--------------------+

клиент PMS--->|открытый ключ сервера|--------------->|закрытый ключ сервера|---> сервер PMS

              +-------------------+                +--------------------+

В конце этого процесса, программа-клиент и веб-сервер Google теперь имеют одинаковые биты PMS. Каждая сторона использует эти биты для генерации секрета, а затем и симметричного ключа шифрования/дешифрования, известного как сеансовый ключ. Теперь есть два разных, но идентичных сеансовых ключа, по одному на каждой стороне соединения. В примере клиента, сеансовый ключ относится к разновидности AES128. Сгенерированный как на стороне программы-клиента, так и на стороне веб-сервера Google, сеансовый ключ на каждой стороне сохраняет конфиденциальность диалога между двумя сторонами. Например, протокол согласования Диффи-Хеллмана позволяет повторять весь процесс PMS, если одна из сторон (например, программа-клиент) или другая (в данном случае веб-сервер Google) требует перезапуск согласования.

Заключение

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

От редакции

Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.
*Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube. com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.

/docs/man1.1.1/man1/openssl-rsa.html

НАЗВАНИЕ

openssl-rsa, rsa — средство обработки ключей RSA

ОБЗОР

openssl rsa [-помощь ] [— сообщить PEM|DER ] [ -outform PEM|DER ] [ -входящее имя файла ] [ -passin arg ] [ -исходящее имя файла ] [ -passout arg ] [ -aes128 ] [ -aes192 ] [ -aes256 ] [ -aria128 ] [ -aria192 ] [ -aria256 ] [ -camellia128 ] [ -camellia192 ] [ -camellia256 ] [ -des ] [ -des 3 ] [ — идея ] [ — текст ] [ -noout ] [ -modulus ] [ -check ] [ -pubin ] [ -pubout ] [ -RSAPublicKey_in ] [9000 9 -RSAPublicKey_out ] [ -идентификатор двигателя ]

ОПИСАНИЕ

Команда rsa обрабатывает ключи RSA. Их можно преобразовывать между различными формами и распечатывать их компоненты. Примечание эта команда использует традиционный формат, совместимый с SSLeay, для шифрования с закрытым ключом: новые приложения должны использовать более безопасный формат PKCS#8 с помощью утилиты pkcs8 .

ОПЦИИ

-помощь

Распечатать сообщение об использовании.

-Информ ДЕР|ПЭМ

Указывает формат ввода. Параметр DER использует закодированную форму ASN1 DER, совместимую с форматом PKCS#1 RSAPrivateKey или SubjectPublicKeyInfo. 9Форма 0009 PEM является форматом по умолчанию: она состоит из формата DER base64, закодированного с дополнительными строками заголовка и нижнего колонтитула. При вводе также принимаются закрытые ключи формата PKCS#8.

— внешний DER|PEM

Указывает выходной формат, параметры имеют то же значение и значение по умолчанию, что и параметр -inform .

-в имени файла

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

-пароль аргумент

Источник пароля входного файла. Дополнительные сведения о формате arg см. в разделе «Параметры парольной фразы» в openssl(1).

— имя файла

Указывает имя выходного файла для записи ключа или стандартного вывода, если этот параметр не указан. Если установлены какие-либо параметры шифрования, будет запрошена парольная фраза. Имя выходного файла должно быть , а не , совпадать с именем входного файла.

— пароль доступа

Источник пароля выходного файла. Дополнительные сведения о формате arg см. в разделе «Параметры парольной фразы» в openssl(1).

-aes128 , -aes192 , -aes256 , -aria128 , -aria192 , -aria256 , -camellia128 , -camellia192 , -camellia256 , -des , -des3 , -идея

Эти параметры шифруют закрытый ключ с помощью указанного шифра перед его выводом. Запрашивается парольная фраза. Если ни один из этих параметров не указан, ключ записывается в виде обычного текста. Это означает, что использование утилиты rsa для чтения зашифрованного ключа без опции шифрования можно использовать для удаления фразы-пароля из ключа или путем установки параметров шифрования, которые можно использовать для добавления или изменения фразы-пароля. Эти параметры можно использовать только с выходными файлами формата PEM.

-текст

Распечатывает различные компоненты открытого или закрытого ключа в виде простого текста в дополнение к закодированной версии.

-ноут

Эта опция запрещает вывод закодированной версии ключа.

-модуль

Эта опция выводит значение модуля ключа.

-чек

Этот параметр проверяет согласованность закрытого ключа RSA.

-паб

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

-пабаут

По умолчанию выводится закрытый ключ: с этой опцией вместо него будет выведен открытый ключ. Этот параметр устанавливается автоматически, если ввод является открытым ключом.

-RSAPublicKey_in , -RSAPublicKey_out

Нравится -pubin и -pubout кроме Вместо этого используется формат RSAPublicKey .

-идентификатор двигателя

Указание механизма (по его уникальной строке id ) приведет к тому, что rsa попытается получить функциональную ссылку на указанный механизм, тем самым при необходимости инициализируя его. Затем этот движок будет установлен по умолчанию для всех доступных алгоритмов.

ПРИМЕЧАНИЯ

Формат закрытого ключа PEM использует строки верхнего и нижнего колонтитула:

 -----НАЧАЛО ЗАКРЫТОГО КЛЮЧА RSA-----
 -----END RSA PRIVATE KEY-----

Формат открытого ключа PEM использует строки заголовка и нижнего колонтитула:

 -----BEGIN PUBLIC KEY-----
 -----END PUBLIC KEY-----

Формат PEM RSAPublicKey использует строки заголовка и нижнего колонтитула:

 -----BEGIN RSA PUBLIC KEY-----
 -----КОНЕЦ ОТКРЫТОГО КЛЮЧА RSA-----

ПРИМЕРЫ

Чтобы удалить фразу-пароль для закрытого ключа RSA:

 openssl rsa -in key. pem -out keyout.pem

Чтобы зашифровать закрытый ключ с помощью тройного DES:

 openssl rsa -in key.pem -des3 -out keyout.pem

Чтобы преобразовать закрытый ключ из формата PEM в формат DER:

 openssl rsa -in key.pem - outform DER -out keyout.der

Чтобы вывести компоненты закрытого ключа в стандартный вывод:

 openssl rsa -in key.pem -text -noout

Чтобы просто вывести открытую часть закрытого ключа:

 openssl rsa -in key.pem -pubout -out pubkey.pem

Вывести открытую часть закрытого ключа в формате RSAPublicKey :

 openssl rsa -in key.pem -RSAPublicKey_out -out pubkey.pem

ОШИБКИ

вручную редактировать их.

СМОТРИТЕ ТАКЖЕ

pkcs8(1), dsa(1), genrsa(1), gendsa(1)

АВТОРСКОЕ ПРАВО

Copyright 2000-2021 Авторы проекта OpenSSL. Все права защищены.

Под лицензией OpenSSL («Лицензия»). Вы не можете использовать этот файл, кроме как в соответствии с Лицензией. Вы можете получить копию в файле LICENSE в исходном дистрибутиве или по адресу https://www.openssl.org/source/license.html.

/docs/manmaster/man1/openssl-rsa.html

НАЗВАНИЕ

openssl-rsa — команда обработки ключа RSA

ОБЗОР

openssl rsa 900 10 [-помощь ] [-информ ДЕР | ПЕМ | Р12 | ДВИГАТЕЛЬ ] [-outform DER | PEM ] [ -in имя файла | uri ] [ -passin arg ] [ -out имя файла ] [ -passout аргумент ] [ -aes128 ] [ -aes192 ] [ -aes256 ] [ -aria12 8 ] [ -aria192 ] [ -aria256 ] [ -camellia128 ] [ -camellia192 ] [ -camellia256 ] [ -des ] [ -des3 ] [ -idea ] [ 90 009 -текст ] [ -ноут ] [ — модуль ] [ -традиционный ] [ -check ] [ -pubin ] [ -pubout ] [ -RSAPublicKey_in ] [ -RSAPublicKey_out ] [ -pvk-strong ] [ -pvk-weak ] [9000 9 -ПВК-нет ] [ -двигатель id ] [ -provider name ] [ -provider-path path ] [ -propquery propq ]

DE SCRIPTION

Эта команда обрабатывает ключи RSA. Их можно преобразовывать между различными формами и распечатывать их компоненты.

ОПЦИИ

-помощь

Распечатать сообщение об использовании.

-Информ ДЕР | ПЕМ | Р12 | ДВИГАТЕЛЬ

Ключевой формат ввода; по умолчанию не указано. См. подробности в openssl-format-options(1).

-outform DER | ПЕМ

Ключевой формат вывода; по умолчанию PEM . См. подробности в openssl-format-options(1).

— традиционный

При записи закрытого ключа используйте традиционный формат PKCS#1 вместо формата PKCS#8.

-in имя файла | ури

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

-пропуск аргумент , -проход аргумент

Источник пароля для входного и выходного файла. Для получения дополнительной информации о формате arg см. openssl-passphrase-options(1).

-выход имя файла

Указывает имя выходного файла для записи ключа или стандартного вывода, если этот параметр не указан. Если установлены какие-либо параметры шифрования, будет запрошена парольная фраза. Имя выходного файла должно быть , а не , совпадать с именем входного файла.

-aes128 , -aes192 , -aes256 , -aria128 , -aria192 , -aria256 , -camellia128 , -camellia192 , -camellia256 , -des , -des3 , -идея

Эти параметры шифруют закрытый ключ с помощью указанного шифра перед его выводом. Запрашивается парольная фраза. Если ни один из этих параметров не указан, ключ записывается в виде обычного текста. Это означает, что эту команду можно использовать для удаления фразы-пароля из ключа, не указывая никаких параметров шифрования, или для добавления или изменения фразы-пароля путем их установки. Эти параметры можно использовать только с выходными файлами формата PEM.

-текст

Распечатывает различные компоненты открытого или закрытого ключа в виде простого текста в дополнение к закодированной версии.

-ноут

Эта опция запрещает вывод закодированной версии ключа.

-модуль

Эта опция выводит значение модуля ключа.

-чек

Этот параметр проверяет согласованность закрытого ключа RSA.

-паб

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

-пабаут

По умолчанию выводится закрытый ключ: с этой опцией вместо него будет выведен открытый ключ. Этот параметр устанавливается автоматически, если ввод является открытым ключом.

-RSAPublicKey_in , -RSAPublicKey_out

Аналогично -pubin и -pubout , за исключением того, что вместо используется формат RSAPublicKey .

-ПВК-сильный

Включить «Сильный» уровень кодирования PVK (по умолчанию).

-ПВК-слабый

Включить «Слабый» уровень кодирования PVK.

-ПВК-нет

Не применять кодировку PVK.

-двигатель идентификатор

См. «Параметры движка» в openssl(1). Эта опция устарела.

-поставщик имя
-провайдер-путь путь
-propquery propq

См. «Параметры поставщика» в openssl(1), provider(7) и property(7).

ПРИМЕЧАНИЯ

Команда openssl-pkey(1) способна выполнять все операции, которые может выполнять эта команда, а также поддерживает другие типы открытых ключей.

ПРИМЕРЫ

Документация по команде openssl-pkey(1) содержит примеры, эквивалентные приведенным здесь.

Чтобы удалить парольную фразу из закрытого ключа RSA:

 openssl rsa -in key.pem -out keyout.pem

Чтобы зашифровать закрытый ключ с помощью тройного DES:

 openssl rsa -in key.pem -des3 - out keyout.pem

Чтобы преобразовать закрытый ключ из формата PEM в формат DER:

 openssl rsa -in key.pem -outform DER -out keyout.der

Чтобы вывести компоненты закрытого ключа в стандартный вывод:

 openssl rsa -in key.pem -text -noout

Чтобы просто вывести открытую часть закрытого ключа:

 openssl rsa -in key.pem - pubout -out pubkey.pem

Вывести открытую часть закрытого ключа в формате RSAPublicKey :

 openssl rsa -in key.pem -RSAPublicKey_out -out pubkey.pem

ОШИБКИ

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

No related posts.