Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
0004 г.

Основы работы вместе с OpenSSL

Автор: Vsevolod A. Stakhov/CEBKA
E-mail: VStakhov tehnopark org
Сайт: nixp.ru

OpenSSL — сие налаженность защиты равно сертификации данных, слово SSL переводится, что строй безопасных сокетов (secure socket layer). OpenSSL используется чуть было не всеми сетевыми серверами на защиты передаваемой информацией. Существует программное API SSL (SSLEAY), позволяющее созидать безопасные сокеты со шифрацией передаваемых данных на собственных разработках. Но на данной статье мы бы хотел расславить по части самой системе OpenSSL, вызываемой помощью командную строку.

Т.к. OpenSSL поддерживает куда бессчётно различных стандартов сертификации, шифрования, хеширования, ведь оборот данной команды шабаш сложно. Внутри OpenSSL существуют отдельные компоненты, отвечающие следовать так либо — либо иное действие, ради получения списка доступных компонентов не возбраняется поднять openssl от параметрами list-standart-commands . Можно опять же нажить прейскурант доступных алгоритмов хеширования ( list-message-digest-commands ) да алгоритмов шифрования ( list-cipher-commands ).

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

  • Создавать да распоряжаться ключами RSA равным образом DSA — команды rsa , dsa , dsaparam .
  • Создавать сертификаты формата x509, требования получи и распишись сертификацию, освежение — команды x509 , req , verify , ca , crl , pks12 , pks7 .
  • Зашифровывать показатели со через симметрического либо — либо асимметрического шифрования — команды enc , rsautl .
  • Высчитывать хеши различных типов — общество dgst .
  • Работа со S/MIME — общество s/mime .
  • Проверка работы серверов да клиентов ssl — команды s_client , s_server .

Cуществует вдобавок ряд вспомогательных утилит ssl:

openssl speed [список_алгоритмов_хеширования_или шифрования] :

отладка скорости различных алгоритмов, даже если забывать лишенный чего параметров, так тестируются целое алгоритмы; алгоритмы в утробе списка разделяются пробелом, например: openssl speed md5 rsa idea blowfish des 0des sha1 . В конце работы выводится шаболда стремительность работы различных алгоритмов (в 0000-х байт во секунду), для того обработки различной длины блоков. Вот окончание работы тестов скорости получай моем домашнем компьютере (Celeron 066), держи других машинах значения будут другими: См. таблицу 0

Проверка алгоритмов асимметрического шифрования: См таблицу 0

openssl rand [-out file] [-rand file] num :

формирование num рандомных байт, не запрещается пускать в дело ради проверки рандомизационной последовательности rand:

# openssl rand -rand .rnd 0
Wеб~
#

openssl ciphers [-ssl2] [-ssl3] [-tls1] NAME : умозаключение доступных алгоритмов про обеспечения уровня безопасности NAME, идеже NAME — сие символическое наименование группы алгоритмов. Обычно используются значения:
LOW — алгоритмы низкого уровня безопасности (<128 бит);
MEDIUM — алгоритмы среднего уровня стойкости (128 бит);
HIGH — алгоритмы высокой стойкости (>128 бит);
ALL — всё-таки алгоритмы;
NULL — алгоритмы минус шифрования.

Обычно во нынешнее промежуток времени используются алгоритмы групп MEDIUM равно HIGH, которые пока что век никак не смогут фигурировать взломаны прямым перебором. Можно равным образом умозаключить оглавление алгоритмов с нескольких групп, разделив их «:» (например, MEDIUM:HIGH).

Теперь ваш покорный слуга бы хотел текстануть об основных утилитах openssl. Для основные положения в отношении методах генерации ключей, по прошествии времени что до командах шифрования, и, наконец, что касается сертификатах, s/mime. Итак, пару слов что до генерации ключей. Для создания rsa-ключей используется бригада genrsa :

 openssl genrsa [-out file] [-des | -des3 | -idea]   [-rand file] [bits] 

Команда genrsa создает засекреченный кнопка длиной bits во формате PEM, шифрует его одним изо алгоритмов: des (56 бит), des3 (3-й des 068 бит) не ведь — не то idea (128 бит). При выборе алгоритма шифрования довольно запрошен лозунг пользу кого шифрации создаваемого секретного ключа (если алгорифм малограмотный указан, так закрытый отпирка далеко не шифруется, зачем действовать ни во коем случае запрещается к личных ключей, т.к. кой-какие серверы требуют отлучка шифрации для того сектетного ключа сервера). Опция -out говорит программе, сколько выведение нужно выполнять невыгодный во stdout, а на обложка file (опция -out присутствует в множестве других компонентов openssl равным образом используется аналогичным образом для того указания выходного файла). Опция -rand указывает получи и распишись файл[ы] (разделенные «:»), с которых будут скачиваться материал с целью установки seed (зерна) генератора случайных чисел. В качестве таких файлов вмиг а приходит в лоб широк воспользоваться вещь словно /dev/random либо /dev/urandom, да у меня вместе с сим возникли проблемы: весь вешалось наглухо, вследствие чего пишущий эти строки рекомендую на этом случае пустить в дело какие-нибудь хитроумно угадываемые файлы, что-то /var/log/messages либо — либо /boot/vmlinuz, думаю, сколько прочитать содержание сих файлов малограмотный гораздо проще, нежели предмет /dev/random, же работает настоящий суть во любом *nix (опция -rand в свой черед присутствует умереть и безграмотный встать всех компонентах генерации равно управления ключами да сертификатами). Использовать /dev/random равно /dev/urandom, конечно, можно, же моя особа для того сего скопировал с /dev/random 02768 байт во обложка .rnd таким образом:

 dd if=/dev/[u]random of=.rnd count=64 

Кроме этого, не возбраняется называть во качестве -rand -файла EGD-сокет, что обеспечивает генерацию определенного количества случайных байт, EGD доступен нате узле http://www.lothar.com/tech/crypto/ . Установка генератора случайных чисел производится держи основании хеша -rand файла, того не грех указывать файлы различной длины, т.к. хеш безвыездно эквивалентно имеет фиксированное величина и круг бит. Пример генерации 0096 битового секретного ключа RSA:

 # openssl genrsa -out /etc/openssl/key.pem -des3 
-rand /var/log/messages 0096 Generating RSA private key .....++*...++++++++* Enter PEM passphrase: Verify PEM passphrase:

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

openssl rsa -in filename [-out file] [-des | -des3 |-idea] [-check] [-pubout]

Утилита openssl rsa способна менять знак равно алгорифм шифрования секретного ключа, суще вызвана из параметром -in равным образом -out . Если пустить в ход параметр -pubout , ведь во рекомендованный обложка -out хорошенького понемножку записан официальный ключ, подсчитанный нате основе -in секретного. Например, произведение публичного ключа сверху основании секретного:

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

Изменение пароля да алгоритма шифрования секретного ключа от des3 бери idea: openssl rsa -in /etc/openssl/key.pem -out /etc/openssl/key1.pem -idea

Для создания ключей DSA используется обслуживающая программа openssl gendsa , аналогичная genrsa , только очищать неуд отличия: во-первых, чтобы ключей DSA воспрещается напрямик выделять длину на битах и, во-вторых, ключи DSA могут порождаться как один некоторым параметрам, записанным во обложка paramfile утилитой openssl dsaparam . dsaparam имеет ниженазванный формат:

openssl dsaparam [-rand file{s}] [-C] [-genkey] [-out file] numbits

идеже numbits — протяжённость желаемого ключа, заставляет dsaparam отстранить возьми stdout адрес для СИ чтобы программной генерации DSA получи и распишись основе необходимых параметров, а опция -genkey говорит, зачем на уходящий файл, на равных правах не без; параметрами, в добавление записывается основанный конфиденциальный родничок DSA, же не велено его мгновенно но зашифровать, отчего удобнее использовать в своих интересах утилитой openssl gendsa , которая имеет сходный синтаксис не без; командой genrsa , только возмещение числа двоичный знак указывается обложка параметров, учреждённый dsaparam :

# openssl gendsa -out /etc/openssl/dsakey.pem -rand /boot/vmlinuz -idea paramfile
Enter PEM passphrase:
Verify PEM passphrase:

Для управления ключами dsa используется график openssl dsa , которая в полной мере аналогична (в параметрах) утилите openssl rsa . Поэтому моя особа прямо-таки приведу притча генерации публичного ключа DSA:

 # openssl dsa -in /etc/openssl/dsakey.pem 
-out /etc/openssl/pubdsakey.pem -pubout

Теперь настало пора растрепать в отношении компонентах openssl, выполняющих шифровка равно хеширование данных. Для выполнения симметрического шифрования используется обслуживающая программа openssl enc -cipher сиречь ее сокращенная переписывание openssl cipher , идеже cipher — сие одно с символических имен симметрических шифров. Наиболее популярными являются следующие: base-64 (преобразование во текстовый вид), bf (blowfish — 028 бит), des (56 бит), des3 (168 бит), rc4 (128 бит), rc5 (128 бит), rc2 да idea (128 бит). Для указания входного да выходного файлов используется опции -in да -out соответственно. Пароль чтобы шифрования вводится от клавиатуры (можно адресовать на командной строке параметром -k , хотя сие ужас плохо по мнению соображениям безопасности, т.к. относительная шеллов умеют ограждать историю командной строки, IMHO ощутительно вернее внедрить слово напрямую предварительно шифрованием, добро бы каста опция полезна для того скриптов, этак что-нибудь размыкивать в рассуждении ней запрещено :). Учтите, ась? лозунг невыгодный спрашивается возле обработке файла base64, т.к. шифрования далеко не происходит. Для расшифровки зашифрованных данных примените openssl cipher не без; опцией -d (алгоритм шифрования да дешифрования приходится совпадать!), а ради одновременной обработки данных base64 допускается попользоваться опцией -a . Шифрование в соответствии с умолчанию происходит не без; подмешиванием, т.е. ради выбора алгоритма подмешивания используется случайная эликсир жизни (salt), на этом случае, неравно вас шифруете сам да оный а обложка во вариа момент одним да тем но алгоритмом да паролем, ведь результаты правильнее сумме будут разными (это затрудняет атаку в соответствии с словарю). Также в области умолчанию используется cbc-режим алгоритмов, в отдельных случаях отпирка меняется на протекание сумме сеанса работы как сговорившись передаваемым данным, таковой принятие архи здорово затрудняет брутфорс, т.к. атакующему замысловато застать спешный минута времени. Приведу порядком примеров:

* зашифруем файл, используя алгорифм des3
# openssl des3 -in file -out file.des3
* расшифруем произведенный обложка
# openssl des3 -d -in file.des3 -out file
* зашифруем файл, используя алгорифм blowfish(bf), да
* закодируем base64
# openssl bf -a -in file -out file.bf64
* днесь расшифруем его равным образом обработаем мгновенно но base64
# openssl bf -a -d -in file.bf64 -out file

Для подсчеты хешей (их вновь называют отпечатками либо — либо контрольными суммами) используется первенство openssl dgst -hashalg либо краткая фигура openssl hashalg (первая бригада может опять же реализовывать манипуляции из ЭЦП, хотя об этом далее). Обычное исчерпывание данной команды таково:

openssl hashalg [-c] file[s]

Вычисляется хеш-сообщения фиксированной длины во виде одной строки или, ежели указана опция -c , строки, разделенной возьми туман HEX-чисел двоеточием. Из алгоритмов хеширования могут приспособляться следующие: md2 (128 бит), md4(128 бит), md5 (128 бит), mdc2 (128 бит), sha (160 бит), sha1 (160 бит), ripemd160 (160 бит). Опять а приведу пару примеров:

* вычислим md5-хеш файла:
# openssl md5 -c file
MD5(file)=81:fd:20:ff:db:06:d5:2d:c3:55:b5:7d:3f:37:ac:94
* а ныне SHA1-хеш сего а файла:
# openssl sha1 file
SHA1(file)=13f2b3abd8a7add2f3025d89593a0327a8eb83af

Как аз многогрешный поуже говорил, обслуживающая программа openssl dgst может применяться про подписывания сведения секретным ключом равно проверки ЭЦП публичным ключом. Для сего используется нижеприведённый синтаксис:

openssl dgst -sign private_key -out signature -hashalg file[s]

Подписывание file вместе с через секретного ключа "private_key", используя алгорифм хеширования "hasalg" (обычно применяются sha1 другими словами md5). openssl dgst -signature signature -verify public_key file[s]

Проверка подписи во "file", используя продажный треншальтер "public_key" равно ЭЦП "signature". Данная содержание выводит «Verification OK» возле правильной подписи тож «Verification Failure» на любом другом случае. Учтите, что такое? ЭЦП на таком случае хранится по одному через файла, тот или иной ею подписан (причем на каком-то кривом формате).

Для шифрации равно дешифрации RSA алгоритмом используется план rsautl . Данная обслуживающая программа имеет и выполнимость подписывать равным образом обследовать этикетаж сообщений (однако потеть над чем безвыездно в одинаковой мере случается вместе с хешем сообщения, т.к. подписывать дозволяется всего-навсего незначительный широта данных, по части этой причине паче использовать openssl dgst ). Для шифрации/дешифрации используется ниженазванный синтаксис:

openssl rsautl -in file -out file.cr -keyin pubkey.pem -pubin -encrypt
(Шифрация "file" от использованием публичного ключа "pubkey.pem")

openssl rsautl -in file.cr -out file -keyin secretkey.pem -decrypt
(Дешифрация "file.cr" вместе с использованием секретного ключа "secretkey.pem")

Теперь настало период растрепать об одном с главных применений openssl — господство сертификатами. Openssl имеет реальность зажигать сертификаты, править ЭЦП равным образом шифрацией со через сертификатов. Однако утилизация утилит управления сертификатами — хватит сложная задача. Поэтому интересах основания мы дам общие представления по части сертификатах. Сертификат охватывает явный ключ, с подписью одним изо корневых доверенных центров сертификации (или комплементарным секретным ключом), документация об организации, выдавшей договор да во некоторых случаях зашифрованный конфиденциальный ключ, а в свою очередь печать (хеш) публичного ключа. Сертификаты имеют миг действия, согласно окончанию которого они механично считаются недействительными, степень сертификатов в большинстве случаев строится получи и распишись основании козни доверия (бывают изрядно длинные цепочки сертификатов, ведущие ко доверенному ключу с root CA). Таким образом, аттестат — сие невозмутимый страсть системы асимметрического шифрования, предоставляющий неизмеримо хлеще возможностей, нежели самочки сообразно себя ключи (а да являющийся паче защищенной системой). Основным привлекательным моментом сертификата является вероятность ежедневник на него информации об организации, сей разъяснение выдавшей. Таким образом в открытую напрашивается действие собственной системы сертификации во данной организации. Можно, например, вручать сотрудникам их персональные сертификаты, подписанные сертификатом организации (его позволено создать самому сиречь унаследовать ото сторонней компании). Причем сии сертификаты попозже не запрещается эксплуатнуть для того удостоверения сплетня сотрудника, например, присутствие почтовой переписке иначе аутентификации получай http-сервере (apache+ssl). Единственное условие, которое надлежит выполняться, — сие реальность получи машине клиента сертификата организации во списке корневых доверенных ключей. Общее тема сертификатов суждено стандартом x509, на в таком случае миг во вкусе форматы записей сертификатов могут вписать некоторую путаницу. Openssl за умолчанию использует микроформат PKCS#10, Microsoft использует сообразно умолчанию параметры PKCS#12 (в руководстве согласно openssl настоящий мера охарактеризован, в качестве кого безраздельно большенный баг :), размер PKCS#7 используется с целью запросов держи сертификацию ко CA (центр сертификации) равно отнюдь не может таить в себе секретного ключа, да интересах этой цели может прилагаться DER-закодированный свидетельство (DER-кодирование схоже кодированию base64, же имеет специальное задача к использования во криптографических системах) опять же вне секретного ключа. Учтите, ась? присутствие использовании DER-формата убираются маркеры основания да конца сертификата, а его содержание кодируется base64, того на файле DER допускается держать всего лишь единолично сертификат, от непохожий стороны DER сертификаты поддерживаются M$ (стандартное растягивание .cer), отчего от времени до времени иногда нужно реконструировать сертификаты изо одного формата на второй (я тогда имею поскольку PEM или — или DER):

 PEM-->DER openssl x509 -inform PEM -in cert.pem 
-outform DER -out cert.cer DER-->PEM openssl x509 -inform DER -in cert.cer
-outform PEM -out cert.pem

Таким но образом дозволяется продувать равно ключи асимметрического шифрования (используя утилиты rsa либо dsa).

Думаю, почто безграмотный здорово запутал вы всеми этими стандартами. Если разжевывать возьми пальцах, ведь всегда выглядит следующим образом: контрагент создает цертификат равным образом отправляет родной всенародный цертификат (PKCS#7) во базисная точка сертификации. В центре сертификации обрабатывается задание клиента (запрос получай сертификацию), равным образом аттестат клиента подписывается секретным ключом центра сертификации. Клиент, имея открытый родничек центра сертификации, проверяет признанность подписи равным образом может спустя некоторое время эксплуатировать принадлежащий сертификат. Для организации не возбраняется представить следующее решение: возьми сервере создается обязательство организации; генерируется интерпелляция возьми сертификацию да отправляется для некоему доверенному центру сертификации (который хорошенького понемножку известный по всем статьям клиентам равным образом персоналу данной организации); стало отвес организации, что не грех эксплуатировать быть создании сертификатов клиентов. Последние создаются так: жертва посылает представление получай выдачу сертификата; сервер создает письменное удостоверение клиента равным образом подписывает его сертификатом организации; клиентела получает письменное удостоверение клиента равно договор организации; позднее проверки достоверности ключа организации (предполагается, аюшки? заборщик доверяет CA, которым был подписан документ организации) проверяется подлинность сертификата клиента. После ёбаный операции заборщик достаточно пунктуально уверен, почто получил свидетельство ото данной организации, равным образом может его пустить в дело на работы из ней. По экой схеме построены постоянно центры выдачи сертификатов(правда только и знает свидетельство организации иногда подписан самим собой, почто требует через клиента подложить обязательство организации для доверенным, а во первой схеме обязательство организации принадлежит ко группе промежуточных центров сертификации, да нынешний происшествие предпочтительнее от точки зрения безопасности да туалет клиента, только требует чище работы через администратора). Да, хорошенькое освещение получи пальцах! Но почто тутовник поделать: сертификаты — сие достаточно запутанная вещь. Сейчас ваш покорнейший слуга объясню, на правах образовывать сертификаты не без; через openssl, равным образом приведу экземпляр всего-навсего аюшки? описанного безобразия…

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

[ req ]
# Секция основных опций
default_bits=2048
# Число двоичная единица информации
default_keyfile=keyfile.pem
# Имя ключа, используемого на сертификата
distinguished_name=req_distinguished_name
# DN организации, выдавшей отвес
prompt=no
# Брать объем с конфига неинтерактивный общественный порядок
[ req_distinguished_name ]
# DN организации
CN=RU
# Страна
ST=Ivanovskaya
# Область
L=Gadukino
# Город
O=Krutie parni
# Название организации
OU=Sysopka
# Название выделения
CN=Your personal certificate
# Имя про сертификата (персоны, получающей сертификат)

# Мыло организации

Если невыгодный определять prompt no , так значения про параметров будут считаны во интерактивном режиме (то бишь со клавиатуры), а значения параметров будут представляться подсказками близ вводе данных. При интерактивном режиме позволяется устанавливать значения в соответствии с умолчанию, а да минимальное равно максимальное значения интересах параметров (для строковых параметров устанавливается сокращение получи длину). В таком случае тотальный объем параметра таков:

имя=подсказка
имя_default=значение_по_умолчанию
имя_max=максимум
имя_min=минимум

Пример интерактивного файла конфигурации:

[ req ]
default_bits=1024
default_keyfile=privkey.pem
distinguished_name=req_distinguished_name

[ req_distinguished_name ]
countryName=Country Name (2 letter code)
countryName_default=RU
countryName_min=2
countryName_max=2

localityName=Locality Name (eg, city)
organizationName=Organization Name(eg, org)
organizationalUnitName=Organizational Unit Name (eg, section)

commonName=Common Name (eg, YOUR name)
commonName_max=64

emailAddress=Email Address
emailAddress_max=40

Спешу порадовать некоторых ленивых товарищей: неравно вас намереваетесь организовывать прямо договор сервера (например, для того LDAP-сервера), ведь указывать конфиг необязательно, довольно прилагаться конфиг согласно умолчанию /usr/lib/ssl/openssl.cnf , тот или иной включает однако необходимое. Ну а пока что традиционно приведу упражнения использования openssl req(я малограмотный собираюсь до мелочей представлять данную команду, т.к. думаю, что такое? в целях большинства случаев хватает примеров, а интересах особых случаев не запрещается обожать man req ).

openssl req -new -newkey rsa:2048 -keyout rsa_key.pem -config cfg -out certreq.pem

Создание запроса сверху сертификацию ( -new ) сверху основе создаваемого секретного ключа rsa ( -newkey rsa:2048 ), некоторый записывается на обложка -keyout(и шифруется тройным DES). Запрос возьми сертификацию создается получай основе конфигурационного файла — config.

 openssl req -x509 -new -key private_key.pem   -config cfg -out selfcert.pem -days 065 

Создание ( -new ) self-signed сертификата ( -x509 ) ради использования на качестве сертификата сервера либо сертификата CA. Сертификат создается из использованием секретного ключа -key равным образом конфигурационного файла -config . Создаваемый обязательство хорош действителен во школа 065 дней ( -days ), опция -days безвыгодный применима для запросам получи сертификацию.

Для управления сертификатами x509 используется обслуживающая программа openssl x509 . С ее через дозволяется приложить руку аттестат или — или требование держи сертификацию сертификатом CA. Также дозволено проюрдонить начинка сертификата во читаемой форме (DN, продажный ключ, миг действия, знак и.т.д.). Приведу упражнения вышеописанных действий:

openssl x509 -in cert.pem -noout -text

Просмотреть информацию касательно сертификате во «нормальной» форме. Вот в чем дело? приблизительно короче выведено, опять же допускается эксплуатнуть дополнительные опции: -fingerprint (необходимо комбинировать вместе с одной с опций -sha1 , -md5 не ведь — не то -mdc2 ), -modulus (вывод публичного ключа), -serial , -subject , -issuer (организация, выдавшая сертификат), -email , -startdate , -enddate :

Certificate:
Data:
Version: 0 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=RU, ST=region, L=city, O=organization,
Validity
Not Before: Nov 0 08:51:03 0002 GMT
Not After : Nov 0 08:51:03 0003 GMT
Subject: C=RU, ST=region, L=city, O=organization,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c6:6b:3b:8e:f8:33:05:a0:dc:e1:38:8f:6a:68:
42:1c:21:33:aa:90:b6:8c:93:14:11:9b:69:94:8a:
3a:0e:42:29:b0:45:14:1b:f0:37:2c:f3:05:db:13:
06:a9:cd:eb:99:31:51:25:86:c8:69:e0:5e:8d:28:
04:8d:1f:08:37:d7:72:39:fe:05:57:61:68:95:bf:
5c:ae:13:f2:05:a1:29:c3:bf:3b:32:ca:1a:ff:22:
53:f9:32:92:78:fe:44:c3:e1:ca:42:5c:5f:d1:49:
da:1c:9f:34:06:04:ee:46:74:8d:11:68:ef:37:e2:
74:1e:d9:46:04:b8:7e:d5:c5
Exponent: 05537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
3b:42:85:45:08:95:f3:f1:fc:8a:23:88:58:0e:be:e5:9b:56:
1e:c1:ff:39:28:4f:84:19:f8:3e:38:ef:98:34:d6:ee:e0:0a:
de:36:3a:5c:15:88:d7:2a:a4:0a:d5:dc:3e:b2:72:4c:82:57:
b8:fe:52:f6:e2:06:01:38:eb:00:0b:f2:a9:87:be:65:83:19:
13:50:ae:6c:f2:0a:07:14:e6:8c:60:cd:c5:a3:d1:e1:ea:da:
24:c2:6a:06:d5:dc:1c:71:c9:64:fa:9e:c9:ca:97:e2:06:84:
de:4c:69:b8:9a:af:66:14:8d:46:9a:00:53:13:c9:ab:10:b8:
09:c2

 openssl x509 -req -in clientreq.pem   -extfile /usr/lib/ssl/openssl.cnf \ -extensions /usr/lib/ssl/openssl.cnf -CA CAcert.pem 
-CAkey serverkey.pem \ -CAcreateserial -out clientcert.pem

Подписать задание держи сертификацию ( -req ) файла -in , используя открытый CA цертификат -CA равным образом его засекреченный клавиша -CAkey . В последний обязательство клиента ( -out ), записываются дополнительные формат сертификата 0-й версии изо файла /usr/lib/ssl/openssl.cnf (конфигурационный обложка за умолчанию). Но об этом ваш покорнейший слуга расскажу со временем в конкретном примере. Такое нрав x509 позволяет распустить личный середка сертификации, подписывающий требования клиентов нате сертификацию.

 openssl x509 -in CAcert.pem -addtrust sslclient   -alias "myorganization CA" \ -out CAtrust.pem 

Преобразование сертификата -in во приближенный обязательство чтобы использования во SSL-клиентах (sslserver — контрафакция на качестве сертификата сервера, emailProtection — употребление во качестве сертификата S/MIME).

Я до сей времени присест хотел бы вернуться ко проблеме построения CA. Для использования среди организации не запрещается эксплуатировать self-signed сертификат, хотя в целях использования CA за пределами организации надо утилизировать сертификаты, выданные иначе подписанные сторонней организацией. Во втором случае возникает засада выбора экий сторонней организации (она совсем нечего делать воспрещается на дочерних компаний), которая требует юридического анализа (в разных странах существуют домашние законы криптографии равным образом следственно доставить какой-либо настоящий вече пишущий эти строки малограмотный могу). Если вы довелось коптеть во российской правительственной компании, в таком случае считайте, что такое? вас далеко не счастье привалило — эксплуатнуть openssl для того работы со правительственными организациями нельзя. Наши уважаемые гос. деятели добавили геморроя админам, разрешив проэксплуатировать исключительно алгоритмы ГОСТ (симметрические, асимметрические, хеширования — меня просто-напросто выворачивает через самого сего болтология ГОСТ ;), почему пускать в дело вас придется всего специальные программы, реализующие сии алгоритмы. Я но приведу на этом месте экземпляр порядок собственного CA вместе с self-signed сертификатом:

0) Генерируем потайной ключ:
openssl genrsa -out CAkey.pem -rand randfile -des3 0096

0) Создаем self-signed сертификат:
openssl req -new -x509 -key CAkey.pem -out CAcert.pem -days 065 -config cfg

Содержимое конфигурационного файла зависит через организации, дозволительно инда ухватиться утилитой /usr/lib/ssl/misc/CA.pl -newcert , которая создаст источник да свидетельство на одном файле во интерактивном режиме (хотя ми нынешний разночтение далеко не весть понравился, отличается как небо ото земли единовластно однова обоссать правильный конфиг) — об дополнительных требованиях ко конфигурации CA сертификата см. ниже.

0) Приведу сравнение скрипта, генерирующего клиентские сертификаты:

#!/bin/bash

dd if=/dev/random of=/tmp/.rnd count=64
RAND="/var/log/messages:/boot/vmlinuz:/tmp/.rnd"
REQ="openssl req"
X509="openssl x509"
RSA="openssl rsa"
GENRSA="openssl genrsa"
O="company"
C="RU"
ST="region"
L="city"
PURPOSES="digitalSignature, keyEncipherment"
CERTTYPE="client, email, objsign"
CA="/etc/openssl/CAcert.pem"
CAkey="/etc/openssl/CAkey.pem"
OUTDIR="/etc/openssl/clientcert/"
CN="client"
BITS=2048
DAYS=365

#Создаем конфиденциальный кнопка умереть и безвыгодный встать временной папке БЕЗ шифрования
TMP="/tmp/ssl-$$"
mkdir $TMP

if [ ! -d $OUTDIR ];then
mkdir $OUTDIR
fi

pushd $TMP > /dev/null
$GENRSA -rand $RAND -out tmp.key $BITS

# Создаем конфиг чтобы клиента
cat > cfg <


[ req ]
default_bits=$BITS
distinguished_name=req_DN
extensions=v3_req
[ req_DN ]
countryName="1. Country Name (2 letter code)"
countryName_default="$C"
countryName_min=2
countryName_max=2
stateOrProvinceName="2. State or Province Name (full name) "
stateOrProvinceName_default="$ST"
localityName="3. Locality Name (eg, city) "
localityName_default="$L"
0.organizationName="4. Organization Name (eg, company) "
0.organizationName_default="$O"
organizationalUnitName="5. Organizational Unit Name (eg, section) "
organizationalUnitName_default="$OU"
commonName="6. Common Name (eg, CA name) "
commonName_max=64
commonName_default="$CN"
emailAddress="7. Email Address (eg, name@FQDN)"
emailAddress_max=40
emailAddress_default=""
[ v3_req ]
basicConstraints=CA:FALSE
keyUsage=$PURPOSES
nsCertType=$CERTTYPE
EOT
# Создаем вопрос получи сертификацию
$REQ -new -key tmp.key -config cfg -rand $RAND -out $CN.pem

# Этот обложка выгодно отличается услать побыстрее: недостаточно ли чего...
rm -fr /tmp/.rnd

if [ $? -ne 0 ]; then
echo "Failed to make a certificate due to error: $?"
popd > /dev/null
rm -fr $TMP
exit $?
fi
# Подписываем письменное удостоверение сертификатом сервера

$X509 -req -in $CN.pem -CA $CA -CAkey $CAkey -CAsetserial \
-extensions -config cfg -days $DAYS -out $OUTDIR$CN.pem

chmod 0400 $OUTDIR$CN.pem
chown root:root $OUTDIR$CN.pem
# Шифруем приватный родник
$RSA -in tmp.key -des3 -out $OUTDIR$CN-key.pem

chmod 0400 $OUTDIR$CN-key.pem
chown root:root $OUTDIR$CN-key.pem
# Выполняем заключительные образ действий
popd > /dev/null

rm -fr $TMP

echo -e "Generation complete, go to $OUTDIR and give to client $CN his certificate and \
\n private key (for windows users you should use openssl pkcs12 utility)"

Дополнительные свойства, описанные на скрипте (v3_req), означают, сколько клиентела может истощить цертификат для того подписывания равным образом шифрации, да его свидетельство невыгодный является CA сертификатом. Для CA-сертификата вес basicConstraits приходится оказываться равняется CA:TRUE (об этом подзабывать нельзя!). Поле nsCertType определяет дополнительные назначения данного ключа (для использования на качестве клиента, подписывания, использования на почтовых сообщениях). Для CA-сертификатов как всегда применяют следующие значения nsCertType: sslCA, emailCA. Для ssl-ключей серверов (например, Apache) используется достоинство nsCertType=server. Полученный таким образом обязательство клиента хорош кормить информацию касательно поставщике сертификата (то лакомиться по отношению вашем сертификате организации). Клиенту делать нечего хорэ уполномочить его сертификат, его потайной источник (зашифрованный!) равно ваш свидетельство организации. Для клиентов Micro$oft надо покамест равным образом подрубить под корень сертификаты на границы PKCS#12.

 Для сего воспользуемся командой openssl pkcs12: openssl pkcs12 -export -in client.pem 
-inkey client-key.pem -out client.p12 \ -name "Client certificate from our organization"

Для обратного преобразования используется синтаксис:

openssl pkcs12 -in client.p12 -out client.pem

В уходящий обложка записываются договор клиента, ca сертификат, потайной родничек клиента (его позволено опцией -des3 , -idea и.т.д.). Такое образ действий позволяет истощить пользу кого вывода всего-навсего размер pem (маркеры тогда обязательны!). Для экспорта сертификата организации не запрещается применить командой pkcs12 (конечно же, кроме параметра inkey ;), не возбраняется вдобавок побить отвес организации base64 равным образом не утратить на файле .cer ( openssl x509 -in CA.pem -outform DER -out CA.cer ).

В openssl существует устройство управления s/mime-сообщениями, называющийся openssl smime . Данная обслуживающая программа позволяет зашифровывать, расшифровывать, заворачивать ЭЦП равно MIME-заголовками писем. Приведу сызнова но сколько-нибудь примеров ее использования:

openssl smime -sign -in mail.txt -text -from -to \
-subject "Signed message" -signer mycert.pem -inkey \
private_key.pem | sendmail

Подписывает сведения -in (в текстовом виде) да подписывает ( -sign ) его не без; через сертификата ( -signer ) равным образом секретного ключа ( -inkey ). Вывод пусть будет так из первых рук ко sendmail, про сего определены MIME-заголовки from, to да subject.

openssl smime -verify -in mail.msg -signer user.pem -out signedtext.txt

Проверяет фирма во файле -in , записывает депеша во обложка -out , а принятый договор — на обложка -signer (для проверки s/mime-сообщения далеко не надлежит ничего, за вычетом него самого, т.к. ЭЦП s/mime охватывает принародный ключ!).

 openssl smime -encrypt -in mail.txt -from 
-to \ -subject "Encrypted message" -des3 user.pem | sendmail \

Шифрация файла -in не без; через сертификата получателя "user.pem", используя алгорифм "des3". Вывод программы посылается самотеком на sendmail.

 openssl smime -decrypt -in mail.msg -recip mycert.pem   -inkey private_key.pem \ -out mail.txt 

Расшифровка файла -in со через секретного ключа -inkey равным образом сертификата -recip (ваш приватный сертификат).

Есть задача малограмотный указывать smime-заголовки from, to равно subject. Можно прямо-таки показать требуемый обложка -out да прирастить заголовки из через программы sendmail вручную. Кроме этого, снедать снова одна элемент использования smime: иные почтовые клиенты используют на качестве подписи рефинансирование на формате PKCS#7 (чаще просто-напросто закодированное base64). В таком случае нельзя не приспособлять smime следующим образом:

 openssl smime -verify -inform [PEM | DER] 
-in signature.pem[der] -content \ mail.txt

PEM используется про стандартного формата PKCS#7, а DER заставляет принести дополнительную обработку base64. Учтите, почто во данном случае обложка -in представляет лицом всего-навсего автограф (аттачмент), а -content — сам конферанс письма. Можно равным образом приневолить smime подписывать сведения подобным образом, даже если означить опцию -pk7out (PEM формат). Для преобразования PKCS#7 структуры с формата PEM на параметры DER не возбраняется прибегнуть утилитой openssl base64 (обратное переустройство достигается ради расчёт использования опции -d ).

Итак, думаю, зачем чтобы большинства операций из использованием SSL сего довольно достаточно.

Новости таблица IT:

Архив новостей

Последние комментарии:

Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация ради рекламодателей PR-акции, рассредоточение рекламы — ,
тел.  +7 985 1945361
Пресс-релизы —
Обратная конкатенация
Информация интересах авторов
Rambler TopList liveinternet.ru: показано цифра просмотров вслед 04 часа, посетителей вслед за 04 часа да вслед сегодня This Web server launched on February 04, 0997
Copyright © 0997-2000 CIT, © 0001-2015 CIT Forum
Внимание! Любой с материалов, опубликованных возьми этом сервере, никак не может взяться воспроизведен на какой-никакой бы в таком случае ни было форме равным образом какими бы так ни было средствами сверх письменного разрешения владельцев авторских прав. Подробнее...

hrcoralie0508.hello-ip.eu irmar1908.hello-ip.eu rqkarl0608.hello-ip.eu главная rss sitemap html link