LINUX-BG   Адрес : http://www.linux-bg.org
Сигурни Уеб-услуги: основи на PKI - Част 2 (превод)
От: Rumen
Публикувана на: 9-08-2004
Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=programs&key=364012082
ЧАСТ 2

Следваща стъпка: Създаване на собствени сертификати

Въпреки, че повечето CAs ще Ви генерират двойка ключове заедно със сертификат с публичен ключ, Вие можете сами да си генерирате двойка ключове и (самоподписани) сертификати. Нека преминем стъпка по стъпка необходимите етапи за да можете след това да поискате доверена (сертификационна организация)CA да подпише Вашият сертификат.

Ключовете и сертификатите, генерирани в тези примери могат да бъдат използвани от всяко приложение, поддържащо стандартите: RSA [3], DSA [4] и X.509 [5]. Въпреки факта, че ще ограничим нашите примерни сценарии до Apache [6], Tomcat [7] servlet [8] контейнер, Вие можете да ползвате тези техники с други приложения, включващи Уеб-услуги ползвайки съответно техните конфигурационни методи.

Два работещи инструмента за работа с ключове/сертификати са: OpenSSL [9] - библиотека от криптографски функции с включени програми от команден ред за тяхното изпълнение; и Keytool [10] - програма за работа с ключове и сертификати, включена като част от JDK [11] (платформа за работа и разработка на езика Java) на Sun.

OpenSSL

Тъй като OpenSSL пакета включва и други функции, като SSL/TLS функции, ние тук ще разгледаме само функциите му за генериране и управление на ключове/сертификати. Следната команда генерира RSA частен ключ от който може да се получи публичен ключ:

openssl genrsa -out private_key.pem 2048

Ако желаете да защитите своя частен ключ с парола (една добра идея) - използвайте един от -des, des3 или -idea ключовете, в зависимост от това кои алгоритъм за криптиране на паролата желаете да използвате. Дължината на ключа (в битове) тук е 2048, което е общоприетия минимум за RSA-ключове.

Ако пък искате да генерирате DSA двойка ключове ето двете стъпки. Първо създайте DSA параметър файл:

openssl dsaparam -out dsa_param.pem 2048

След (приключване на) горната стъпка,може да генерирате и реалния DSA-ключ:

openssl gendsa -out private_key.pem dsa_param.pem

Тъй както и в примера с RSA по-горе, ако искате да защитите своя частен ключ с парола използвайте една от следните опции: -des, -des3 или -idea.

И двата примера по-горе използват PEM като изходен формат, който пакетира Base64 ASN1 [12] DER данни с ASCII заглавия (headers). За да преобразувате PEM-файловете към PKCS#12 [13] формат (за ползване с Tomcat или много други Уеб-браузъри) изпълнете следната команда:

openssl pkcs12 -export -in pem_formatted_file -out pkcs12-formatted-file

Все още не сме приключили. Необходим ни е сертификат с публичен ключ, който да работи със съответният частен ключ. Ще започнем със създаване на подписан от нас (самоподписан) X.509 сертификат:

openssl req -new -x509 -key private_key.pem -out certificate.der

Тази команда интерактивно пита потребителя за нужната информация, относно субекта за който се генерира сертификата (Уеб-сървър или потребител), цялата информация се използва за да се идентифицира субекта на сертификата с публичен ключ; тоест да се прикрепи субект към публичният ключ. Ако генерирате този сертификат само с тестова цел това е достатъчно. Обаче за повечето реални приложения е необходимо сертификата да бъде подписан и от доверен CA. Подробностите по този процес са различни за различните CA, но повечето ще изискат и приемат - Искане за Подпис на Сертификат (CSR). Следната командаЗа ще го генерира:

openssl req -new -key private_key.pem -out certificate_request.csr

Забележете, че тази команда се различава от последната само по липсата на -x509 опцията (която самоподписва сертификата). Резултата от тази команда - CSR вече може да бъде изпратен на CA, ползвайки изисквания за това начин. След като CA е проверила идентичността на субекта (отново тези стъпки са различни за различните CA) CA ще издаде подписан сертификат.

Комбинацията от частен ключ и сертификат с публичен ключ вече може да се използва в PKI-съвместими приложения, т.е. да се активират SSL-връзки с Вашият Tomcat servlet контейнер, както ще видим след малко.

Keytool

Генериране на двойки ключове и управление на сертификати с използване на keytool е малко по-просто от използването на OpenSSL. Например, вместо да трябва да създавате отделно PKCS#12 контейнер за ключове, keytool създава Java Контейнер за Ключове (JKS-Java Key Store), като част от процеса на генериране на двойка ключове/сертификат. От друга страна keytool не предлага приблизително еднаква функционалност в сравнение с OpenSSL. Например, keytool не може да вмъква или извежда частни ключове в/от контейнер за ключове.  Започваме с генериране на RSA двойка ключове (заедно с съответния самоподписан сертификат) използвайки keytool:

keytool -genkey -keyalg RSA -keysize 2048 -keystore my_keystore.jks -alias me

Тази команда ще Ви поиска необходимите за сертификата данни, както в примера с OpenSSL по-горе. Опцията -alias Ви позволява да дадете 'име' (псевдоним) на двойката ключ/сертификат в контейнера за ключове. Ако искате да генерирате DSA двойка ключове, изпълнете следната команда:

keytool -genkey -keyalg DSA -keysize 2048 -keystore my_keystore.jks -alias me

Още веднъж, ако искате само да генерирате тестов сертификат, може да спрете до тук. Ако обаче искате доверен CA да подпише Вашият сертификат е необходимо да генерирате CSR със следната команда:

keytool -certreq -alias me -keystore my_keystore.jks -file certificate_request.csr

Сега вече може да изпратите генерираният CSR-файл на своя CA, използвайки изискваните от тях начини. След приключване на процеса на проверка CA ще издаде подписан сертификат.

Пример с Tomcat

Сега след като сме генерирали нашата двойка ключове (публичен/частен) и имаме издаден от CA сертификат с публичен ключ, който върви с тях, вече сме готови да ги използваме. Нашата първа стъпка е да се убедим, че контейнера за ключове е с правилен формат за ползване от Tomcat. Tomcat версия 5 поддуржа само контейнери с ключове във формати - JKS или PKCS#12. Ако сте използвали OpenSSL за създаване на Вашата двойка ключове и съответно искането за подпис на сертификат то е необходимо да поставите своя частен ключ и съответният му сертификат с публичен ключ заедно в PKCS#12-съвместим контейнер за ключове:

openssl pkcs12 -export -in certificate_file -inkey private_key.pem -chain -name tomcat -outfile my_keystore.p12

Тази команда взема файла, съдържащ сертификата с публичен ключ, издаден от CA (certificate_file) и го сдвоява със съответният частен ключ (private_key.pem) в PKCS#12-съвместим контейнер за ключове, задавайки му псевдоним "tomcat", който се ползване от Tomcatе по-подразбиране.

Ако сте генерирали своята двойка ключ/сертификат, използвайки keytool не е необходимо да променяте нищо - keytool създава JKS-съвместими контейнери за ключове. Убедете се обаче, че след като веднъж сте получили подписан от CA сертификат (в отговор на Вашата CSR-заявка по-горе) трябва да поставите този сертификат в своя контейнер за ключове ето така:

keytool -import -alias tomcat -trustcacerts -file certificate_file -keystore my_keystore.jks

Тази команда сдвоява подписаният от CA сертификат (във файла certificate_file) със съответният частен ключ в контейнера за ключове, създаден преди това и задавайки му псевдонима по подразбиране "tomcat".

Почти приключихме. Ншата последна стъпка е да конфигурираме Tomcat да поддържа SSL-връзка като редактираме $TOMCAT_HOME/conf/server.xml файла, добавяйки следния Connector-елемент:



Това дава на Tomcat възможност да следи за SSL-връзки на порт-443. Забележете също, че ако Вашият контейнер за ключове е PKCS#12-съвместим, то трябва да промените параметъра 'keystoreType'. Също така, ако искате да задължите клиентите също да се идентифицират с валидни сертификати (взаимна идентификация), то променете параметъра 'clientAuth' на 'true'.

Също така е важно да проверите дали 'redirectPort'параметъра за не-SSL връзки е настроен да съвпада с този  на SSL. За повече информация за тази и други сървърни конфигурации на Tomcat вижте тук [14].

След като вече сте редактирали конфигурационния файл на сървъра може да рестартирате Tomcat и да проверите Вашата нова SSL-връзка чрез зареждане на адрес: https://localhost:443 във Вашият браузър.

Това подразбира факта, че Вашият браузър работи на същата машина на която е инсталиран Tomcat. Вие ще видите тематичната страница на Tomcat (или това, което сте конфигурирали за Ваше базово приложение), а също Вашият браузър ще индикира наличието на работеща SSL-връзка.

ВРЪЗКИ:
[1]"another article" - http://www.counterpane.com/pki-risks.html
[2]"two" - http://www.apache-ssl.org/7.5things.txt
[3]"RSA" - http://www.rsasecurity.com/rsalabs/node.asp?id=2125
[4]"DSA" - http://www.itl.nist.gov/fipspubs/fip186.htm
[5]"X.509" - http://www.ietf.org/html.charters/pkix-charter.html
[6]"Apache" - http://www.apache.org/
[7]"Tomcat" - http://jakarta.apache.org/tomcat
[8]"servlet" - http://java.sun.com/products/servlets
[9]"OpenSSL" - http://www.openssl.org/
[10]"Keytool" - http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html
[11]"Java Development Kit" - http://java.sun.com/
[12]"ASN.1" - http://asn1.elibel.tm.fr/en/standards
[13]"PKCS#12" - http://www.rsasecurity.com/rsalabs/node.asp?id=2138
[14]"this" - http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/index.html

Приятно четене.

<< lm_sensors + Superkaramba | Сигурни Уеб-услуги: основи на PKI - Част 1 (превод) >>

Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук, но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора, както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.

All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
Linux is copyright by Linus Torvalds.
© Линукс за българи ЕООД 2007
© Slavei Karadjov 1999 - 2006

All rights reserved.

Изпълнението отне: 1 wallclock secs ( 0.29 usr + 0.02 sys = 0.31 CPU)