Публикувана на: 9-08-2004
Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=programs&key=364012082
| 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.
|