Порядок действий, условно, будет такой:
- настраиваем openssl (редактируем
/etc/ssl/openssl.cnf
и CA.sh) ; - создаём директорию под центр сертификации;
- создаём самоподписанный корневой сертификат.
Создание центра сертификации
Настройка openssl
Все ниже следующие действия можно проделать напрямую через команду openssl, но что бы упростить собственную жизнь будем использовать скрипт CA.sh. В некоторых дистрибутивах он называется просто CA. Месторасположение на файловой системе также зависит от дистрибутива. Для gentoo это /etc/ssl/misc/CA.sh
.
Прежде всего ищем файл openssl.cnf
и редактируем его изменяя следующие параметры:
default_days
– этот параметр указывает как долго будет действовать Ваш сертификат, по-умолчанию 365 дней, что мало. Дописываем 0req_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
Поскольку Вам часто придется создавать новые сертификаты, лучше сразу озаботиться созданием скрипта, который будет все делать за Вас. :) Например такого:
- make_client_cert.sh
#!/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