Создание ключей и сертификатов в OpenSSL.

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

# Имя для сертификата  (персоны, получающей сертификат)

emailAddress=certificate@gaduk.ru

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

Если не указывать  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 365 

Создание (-new) self-signed сертификата (-x509) для использования в качестве сертификата сервера или сертификата CA. Сертификат создается с использованием секретного ключа -key и конфигурационного файла -config. Создаваемый сертификат будет действителен в течение 365 дней (-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: 3 (0x2)

        Serial Number: 0 (0x0)

        Signature Algorithm: md5WithRSAEncryption

        Issuer: C=RU, ST=region, L=city, O=organization, OU=Sysopka,

CN=CEBKA/Email=CEBKA@smtp.ru

        Validity

            Not Before: Nov  9 08:51:03 2002 GMT

            Not After : Nov  9 08:51:03 2003 GMT

        Subject: C=RU, ST=region, L=city, O=organization, OU=Sysopka,

CN=CEBKA/Email=CEBKA@smtp.ru

        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: 65537 (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), записываются дополнительные параметры сертификата 3-й версии из файла /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).