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

  1. настраиваем openssl (редактируем /etc/ssl/openssl.cnf и CA.sh) ;
  2. создаём директорию под центр сертификации;
  3. создаём самоподписанный корневой сертификат.

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

Настройка 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

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

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


vpn/sslca.txt · Последние изменения: 2013-08-24 21:17 — Andrew A. Sabitov