Порядок действий, условно, будет такой:

настраиваем openssl (редактируем /etc/ssl/openssl.cnf и CA.sh) ;

создаём директорию под центр сертификации;

создаём самоподписанный корневой сертификат.

Создание центра сертификации

Настройка openssl

Все ниже следующие действия можно проделать напрямую через команду openssl, но что бы упростить собственную жизнь будем использовать скрипт CA.sh. В некоторых дистрибутивах он называется просто CA. Месторасположение на файловой системе также зависит от дистрибутива. Для gentoo это /etc/ssl/misc/CA.sh.

Прежде всего ищем файл openssl.cnf и редактируем его изменяя следующие параметры:

default_days – этот параметр указывает как долго будет действовать Ваш сертификат, по-умолчанию 365 дней, что мало. Дописываем 0

req_distinguished_name – это имя секции, которая содержит описание Вашей организации: имя организации, расположение, контакты и т.п. Лучше отредактировать, что бы потом просто нажимать Enter.

Редактируем скрипт /etc/ssl/misc/CA.sh, ищем строку

DAYS="days 365"

и пишем 7300, вместо 365. В следующей строке задаем

CADAYS="-days 5475"

Первый параметр указывает сколько дней будет действовать сам центр сертификации, а второй – сколько дней будет действовать подпись на сертификаты, подписанные нашим центром. Второй параметр должен быть меньше первого, иначе M$ Windows не будет признавать наш центр авторизации.

Создание CA.

Теперь создаём директорию, в которой будем держать сертификаты.

vpnServer ~ # mkdir /var/sslca vpnServer ~ # chmod 700 /var/sslca

Переходим с созданную директорию, и создаём сам центр авторзации.

vpnServer sslca # /etc/ssl/misc/CA.sh -newca

У Вас появится директория demoCA, пароль который будут спрашивать при создании центра лучше записать на бумажку и положить в надежный сейф. Он Вам будет нужен постоянно.

Создаем файл для отзыва сертификатов

vpnServer sslca # echo 01 > ./demoCA/crlnumber vpnServer sslca # openssl ca -gencrl -out crl.pem

Генерация сертификатов X.509

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

#!/bin/sh echo -n "Input client FQDN host name: " read client_name echo -en "\\033[1;32m New cert generation \\033[0;39m \\015 \\012" echo -n "Input pwd for THIS cert: " read pwd echo Input this \"$pwd\" twice. Use mouse ':)' /etc/ssl/misc/CA.sh -newreq echo -en "\\033[1;32m New cert generation done\\033[0;39m \\015 \\012" echo -en "\\033[1;32m Singing this cert \\033[0;39m \\015 \\012" echo 'You should input MAIN password here.' /etc/ssl/misc/CA.sh -sign echo -en "\\033[1;32m Singing finished \\033[0;39m \\015 \\012" mv newcert.pem ${client_name}.pem mv newkey.pem ${client_name}.key rm -f newreq.pem echo -en "\\033[1;32m Generating composite cert in .p12 format \\033[0;39m \\015 \\012" echo You should input \"$pwd\" 3 times now openssl pkcs12 -export -in ${client_name}.pem -inkey ${client_name}.key -certfile demoCA/cacert.pem -out ${client_name}.p12 echo -en "\\033[1;32m Composite cert in .p12 format generated\\033[0;39m \\015 \\012" if [ ! -e clients ] ; then mkdir clients fi mv ${client_name}.pem ${client_name}.key ${client_name}.p12 clients echo "===============================================================" echo "= All client related files are located in clients directory " echo "= You should copy ${client_name}.p12 file on client host " echo "= Use mmc to import this .p12 cert into Windows repositary " echo "= Good luck! " echo "==============================================================="

Допустим, есть почтовый сервер работу который должен работать поверх SSL. И для постфикса, и для довекота можно использовать один и тот же ключ, при таком подходе никаких проблем мы не заметим. Если же мы попробуем создать два ключа, то subject у этих ключей будет совпадать:

C=RU/ST=Novosibirsk Region/L=Novosibirsk/O=Boreskov Institute of Catalysis, SB RAS/OU=CSD/CN=yam.catalysis.ru/emailAddress=devnull@catalysis.ru

И при попытке создать второй ключ (а точнее на момент его подписывания) мы получим ошибку:

failed to update database
TXT_DB error number 2

Если есть необходимость генерить ключи с одинаковым Subject'ом, то в файле demoCA/index.txt.attr необходимо установить параметр unique_subject в no.

Усё, теперь можно генерить сертификаты на все случаи жизни: для VPN-сервера и его клиентов, апача, постфикса и прочих довекотов. CN (Common Name) в сертификатах для апача, постфикса и т.п. необходимо прописывать в FQDN машины, на которой будет устанавливаться ключ, иначе клиент будет жаловаться, что сертификат выдан на одну машину, а используется на другой. Некоторые клиенты (например, поганый тхебат вообще коннектиться не будут). Для VPN-клиентов удобно этот параметр прописывать в полное имя пользователя.

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

#считаем, что ./make_client_cert.sh успешно отработал :) cd clients/ rm apache_at_www.example.com.p12 # этот файл нам на *nix'ах не нужон openssl rsa -in apache_at_www.example.com.key -out apache_at_www.example.com.key.unenc mv apache_at_www.example.com.key{.unenc,}

Если необходимо сменить пароль на ключе:

cd clients/ openssl rsa -des3 -in apache_at_www.example.com.key -out apache_at_www.example.com.key.new mv apache_at_www.example.com.key{.new,}

После этого файлы apache_at_www.example.com.{pem,key} можно раскладывать куда надо и указывать их в настройках соответствующего демона.

— Andrew A. Sabitov 2011-01-03 20:33

Tracedump:

newBaseSize: 16pt
newBaseSizeInPt: 16