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

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

1) Генерируем секретный ключ:

openssl genrsa -out CAkey.pem -rand randfile -des3 4096 

2) Создаем self-signed сертификат:

openssl req -new -x509 -key CAkey.pem -out CAcert.pem -days 365 -config cfg

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

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

#!/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 < 
 

# Этот файл  лучше удалить побыстрее: мало  ли чего...

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 CEBKA@smtp.ru -to \

            user@mail.ru -subject "Signed message" -signer mycert.pem -inkey \

            private_key.pem | sendmail user@mail.ru 

Подписывает сообщение -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 CEBKA@smtp.ru -to user@mail.ru \

              -subject "Encrypted message" -des3 user.pem | sendmail     \

            user@mail.ru 

Шифрация файла -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 этого будет достаточно.