OpenNET: статья - SSL-сертификаты сайтов, назначение и использование (ssl cert crypt openssl)

Ключевые слова: ssl, cert, crypt, openssl, (найти похожие документы)
From: Рашид Ачилов Date: Mon, 16 Apr 2010 17:02:14 +0000 (UTC) Subject: SSL-сертификаты сайтов, назначение и использование Материал предоставлен редакцией журнала Системный администратор. Опубликовано в журнале "Системный администратор" N 3 2010 Статью можно обсудить на Форуме журнала "Системный администратор" http://www.samag.ru/forum/ Что это такое? Почему недостаточно установить Apache с поддержкой https, чтобы сайт считался безопасным? Как предоставить доступ к корпоративным порталам извне, не устанавливая ключа для каждого? Ты мне веришь или нет? В сентябре 2009 года была опубликована первая статья цикла "Замена Microsoft Exchange на Open Source-решения" [1], в рамках которой предполагается рассказать о том, как можно заменить многофункциональный сервер Microsoft Exchange на не менее многофункциональный Open Source-комплект, который будет делать все то же самое и даже больше. И хотя данная статья не входит в этот цикл напрямую, она имеет к нему самое непосредственное отношение, поскольку первичной задачей было предоставление доступа к корпоративной почте с любого коммуникатора, смартфона или переносного компьютера. Тот факт, что данный сервер доступа должен использовать https для шифрования трафика и быть доступен на нестандартном порту, совершенно очевиден, и как это сделать - приводилось в [6]. Также существует достаточно много материалов на тему установки Apache с модулем SSL (хотя большинство из них - перепечатки либо [2], либо [5]), поэтому будем считать, что у нас уже работает https-сервер на порту, ну, допустим, 20202, использующий ключ http://www.snakeoil.com, поставляемый в качестве образца). Тем не менее, при попытке зайти на наш сайт, браузер непременно отобразит окно предупреждения. Почему же наш сертификат считается недействительным, и как этого избежать? Прежде всего - что такое, собственно, SSL-сертификат. Это своего рода "электронный паспорт" сайта, в котором он подтверждает, что он действительно тот сайт, за который выдает себя. Поскольку https давно и прочно используется для безналичных платежей, в которых не бывает много безопасности, сертификат сайта призван дополнительно подтверждать, что этот сайт - действительно сайт банка, платежной системы и т.д. Собственно, SSL-сертификат, как и всякий паспорт, хранит различные данные: наименование организации и подразделения (если оно есть), страну, регион, город и имя сервера, для которого данный сертификат был создан. И, как и всякий паспорт, он должен быть подписан организацией, которой доверяют все. И если на документе стоит ее подпись - считается, что документ содержит правильную информацию. В России такую роль при выдаче паспортов гражданам выполняет УФМС. А как дела обстоят в мире? А в мире эта система чем-то похожа на DNS - точно так же существует набор некоторых "доверенных" центров (называемых центрами сертификации, Center of Authority, CA), и в том случае, если наш сертификат подписан ключом одного из этих центров, - информация в нем считается верной. Услуга эта не из дешевых, годовая лицензия VeriSign (одного из наиболее известных CA) стоит $1200, но зато, если сертификат сайта подписан каким-либо из "доверенных" CA, считается, что адрес, куда мы зашли, - это в действительности нужный нам сайт, поскольку это гарантируется авторитетом компании, подписавшей наш сертификат. Как же система изначально получает ключи "доверенных" CA? Достаточно просто. Microsoft распространяет их как обновление системы через свой механизм установки обновлений, а другие браузеры, например Firefox, содержат их непосредственно в дистрибутиве. А теперь посмотрим на наш ключ более внимательно. И сразу все становится понятным. Во-первых, наш сертификат никем не подписан. Это все равно что написать на листе бумаги "Паспорт" и пытаться выдавать его за документ. Во-вторых, информация, которая хранится в сертификате, и реальная информация о сайте, различаются (напоминаю, что сейчас у нас установлен тестовый сертификат, созданный для сайта www.snakeoil.com). Еще в сертификате может храниться дата, после которой он перестает действовать. Если не выполняется хотя бы одно из этих условий, а именно: * сертификат должен быть подписан одним из ключей, хранящихся как ключи корневых центров сертификации; * имя сервера, хранящееся в сертификате, должно совпадать с именем открываемой страницы;. * дата истечения срока действия сертификата не должна быть меньше текущей. То тогда сертификат сайта будет считаться "небезопасным" и браузеры будут выдавать соответствующие предупреждения, а то и не пускать на сайт, в зависимости от браузера и его настроек. Каким же образом добиться выполнения всех условий, чтобы не наблюдать постоянно сообщения от "системы безопасности" и не писать инструкции о том, как не обращать внимания на эти сообщения? Имени сервера, точнее говоря, соответствия имени сервера и имени, сохраненного в сертификате, добиться сравнительно легко. Для этого только и необходимо, что установить так называемый "самоподписанный" SSL-сертификат. Как это сделать - достаточно подробно описано в [2] и [5], после чего имя в просматриваемом сертификате www.snakeoil.com заменится на имя нашего сайта. Многие, как правило, на этом и останавливаются. Причем не просто любительские сайты, а сайты провайдеров, сотовых операторов и всех тех, кому не иметь настоящего сертификата, подписанного тем же VesiSign или Thawte, ну просто стыдно. Останавливаются, потому что, пользователю, чтобы убрать сообщение "системы безопасности", нужно установить какой-то ключ, и только после этого браузер успокоится. А если на наш сайт нужно заходить со смартфонов или коммуникаторов, у которых нет возможности принять произвольный ключ непосредственно в сеансе или необходимо авторизоваться на десятке различных корпоративных сайтов? Здесь уже без собственного центра сертификации не обойтись. Чем нам поможет разворачивание CA? Устанавливая собственный CA, мы создаем внутри компании единый центр, подпись которого сертификата сайта будет иметь ту же силу, что и подпись VeriSign... в масштабах компании. Для этого достаточно будет распространить на все компьютеры и мобильные устройства (смартфоны, коммуникаторы) собственный сертификат нашего CA, объявив его корневым, и все ключи, которые были или будут в будущем подписаны им, автоматически станут "безопасными", поскольку их принадлежность может быть проверена. VeriSign собственного изготовления На самом деле развертывание собственного CA - дело не такое уж и сложное и достаточно подробно описано в [4] и [5]. Первым делом надо настроить /etc/ssl/openssl.conf - пример файла уже лежит там, достаточно внести в него приведенные ниже изменения. [ ca ] # Эта секция будет использоваться, если ничего не задано default_ca = CA_default [ CA_default ] dir = . # Корневой каталог (относительно текущего!) certs = $dir/ssl.crt # Здесь будут лежать выданные сертификаты crl_dir = $dir/ssl.crl # Здесь будут лежать списки отзыва database = $dir/index.txt # Это индексный файл базы данных new_certs_dir = $dir/ssl.crt # Место для новых сертификатов certificate = $dir/caserv.crt # Собственный сертификат CA serial = $dir/serial # Файл для хранения текущего серийного номера crl = $dir/ssl.crl/crl.pem # Текущий CRL private_key = $dir/ssl.key/caserv.key # Личный ключ CA [ ssl_server ] basicConstraints = CA:FALSE nsCertType = server keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, nsSGC, msSGC nsComment = "OpenSSL Certificate for SSL Web Server" subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always subjectAltName=email:copy issuerAltName=issuer:copy [ ssl_client ] basicConstraints = CA:FALSE nsCertType = client keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth nsComment = "OpenSSL Certificate for SSL Client" subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always subjectAltName=email:copy issuerAltName=issuer:copy Секции [ssl_server] и [ssl_client] заполнены дополнительной информацией, включаемой в сертификаты в соответствии с man x509v3_config. Их можно и не задавать, в конфигурационном файле по умолчанию они не определены, но их использование повышает читабельность сертификатов. Предполагаем, что вся структура каталогов будет размещаться в /usr/local/etc/apache22/ssl. Если никаких каталогов там нет, то создаем их (необходимые каталоги создавались в apache1 установкой mod_ssl, в apache2 mod_ssl уже включен в дистрибутив): # cd /usr/local/etc/apache22/ssl # mkdir ssl.crl # mkdir ssl.crt # mkdir ssl.csr # mkdir ssl.key # mkdir ssl.prm Создаем главный ключ сертификационного центра: # openssl req -config /etc/ssl/openssl.cnf -new -newkey rsa:1024 \ -keyout caserv.key -x509 -days 7300 -out caserv.cr Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Novosibirskaya Locality Name (eg, city) []:Novosibirsk Organization Name (eg, company) [Internet Widgits Pty Ltd]:LLC "ShelonSoft Inc." Organizational Unit Name (eg, section) []:IT department Common Name (eg, YOUR name) []:bigcat.sheltonsoft.ru EmailAddress []:root@sheltonsoft.ru При задании пароля следует использовать сгенерированый пароль не менее 12 символов длиной - этим паролем будет кодироваться главный ключ, удостоверяющий подлинность всех остальных ключей. При вводе прочей информации будьте внимательны: эта информация будет отображаться как данные об удостоверяющем центре. Ключ создается в формате RSA длиной 1024 бита и будет считаться действующим два года. После создания файлов caserv.key поместить в каталог ssl.key, установить права 0400 и всячески препятствовать попыткам его получить, caserv.crt же - наоборот, выложить в общий доступ и установить в качестве корневого сертификата на все устройства, с которых будут обращаться к сайтам, сертификаты которых предполагается подписывать ключами данного CA. Кроме того, необходимо создать индексный файл базы данных подписанных ключей (имя задается в параметре database секции ca конфигурационного файла) и файл с текущим серийным номером (имя задается в параметре serial секции ca конфигурационного файла): # touch index.txt # echo '01' -> serial Наш CA готов подписывать сертификаты. Но для того, чтобы ему доверяли, необходимо распространить собственный сертификат СА на все устройства, которые будут обращаться на сайты, сертификат которых подписан ключом нашего СА. Впрочем, для стандартных компьютеров сделать это несложно - Windows принимает как PEM-encoded, так и DER-encoded сертификаты, достаточно двойного щелчка - и сертификат откроется для просмотра, а после нажатия кнопки "Установить сертификат" - запустится мастер усановки сертификатов. Необходимо согласиться с предупреждением системы безопасности - и все, наш сертификат успешно установлен. Установка сертификата в качестве корневого в Firefox выполняется непосредственно в самом браузере. Выбираете "Настройки -> Дополнительные -> Шифрование" и нажимаете кнопку "Просмотр сертификатов", выбираете раздел "Центры сертификации" и нажимаете кнопку "Импортировать". Опять нас один раз спросят: а действительно ли мы хотим доверять этому СА ? Для мобильных устройств все будет несколько посложнее. В качестве примера возьмем смартфон Nokia N95 8G. В разделе "Настройки -> Общие -> Защита -> Сертификаты" можно только просмотреть список сертификатов или удалить какой-либо из них. Для добавления сертификата в смартфон необходимо выполнить следующие действия: # openssl x509 -inform PEM -in caserv.crt -outform DER -out caserv.cer Преобразовать его формат - файл *.crt (PEM-encoded) на смартфоне почему-то не распознается как файл сертификата, и его необходимо преобразовать в файл *.cer (DER-encoded): После этого файл можно переносить на смартфон любым стандартным способом. После перемещения файла в смартфон, открыть стандартный менеджер файлов, найти и выбрать файл сертификата, нажать центральную кнопку. Выдается запрос на установку сертификата, затем предупреждение системы безопасности, с которым нужно согласиться, затем выбор режимов доверия к сертификату. Выбираем ОК, сертификат установлен. Но сложнее всего, конечно, установить сертификат в коммуникатор на базе Windows Mobile. В нем в принципе отсутствуют какие-либо средства по управлению сертификатами и даже сама компания Microsoft предлагает только единственный способ, напоминающий взломы игр конца 90-х. Далее нужно создать файл с произвольным именем, расширением .xml и следующим содержанием: <wap-provisioningdoc> <characteristic type="CertificateStore"> <characteristic type="ROOT"> <characteristic type="<certhash>"> <parm name="EncodedCertificate" value="<base64encodedcert>"/> </characteristic> </characteristic> </characteristic> </wap-provisioningdoc> С помощью следующей команды получить "отпечаток" ключа, скопировать текст отпечатка и поместить его вместо <certhash>, удалив двоеточия (так, чтобы получился непрерывный текст): # openssl x509 -in caserv.crt -noout -text -sha1 -fingerprint SHA1 Fingerprint=07:55:6E:18:20:18:01:CB:0A:31:A7:9D:0E:C7:47:34:37:D1:EE:4E Открываем с помощью текстового редактора файл caserv.crt и копируем все, что расположено между строками -----BEGIN SERTIFICATE----- и -----END SERTIFICATE-----. Вставляем скопированный текст вместо раздела <base64encodedcert>, удалив символы перевода строк, если таковые имеются, так, чтобы получилась одна длинная непрерывная строка. Сохранить полученный файл под именем _setup.xml. Упаковать полученный файл в .cab командой (в Windows): > makecab _setup.xml wmcaserv.cab Полностью статья, описывающая этот способ (на английском языке), изложена на [6]. После создания файла установки он стандартным образом переносится на коммуникатор и запускается там. Установка проходит молча, не задавая никаких вопросов. Ну вот, осталось только снабдить все нужные нам сайты ключами, которые вместо того, чтобы быть "самоподписанными", будут подписаны нашим CA. Это выполняется в два этапа. Сначала формируется запрос на сертификацию и закрытый ключ. # openssl req -new -sha1 -newkey rsa:1024 -nodes -keyout <filename>.key \ -out <filename>.pem -config /etc/ssl/openssl.cnf При создании запроса будьте внимательны при ответах на вопросы, особенно при задании CommonName - здесь должно быть задано имя сайта, которое будет указываться в браузерах без префикса https. Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Novosibirskaya Locality Name (eg, city) []:Novosibirsk Organization Name (eg, company) [Internet Widgits Pty Ltd]:LLC "SheltonSoft Inc." Organizational Unit Name (eg, section) []:Web server Common Name (eg, YOUR name) []:www.sheltonsoft.ru Email Address []:webmaster@sheltonsoft.ru Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:123456 An optional company name []:LLC "SheltonSoft Inc." В данном случае ключ запрашивается для сервера с адресом www.sheltonsoft.ru. После создания закрытого ключа и запроса на сертификацию, файл <filename>.key помещается в каталог ssl.key того компьютера, на котором создавался запрос на сертификацию, а файл <filename>.pem передается на тот компьютер, на котором развернут СА, где полученный запрос необходимо подписать, сохранив его для этого в каталог ssl.csr: # openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything \ -out ssl.crt/<filename>.pem -infiles ssl.csr/<filename>.pem # openssl x509 -in ssl.crt/<filename>.pem -out ssl.crt/<filename>.crt Теперь готовый файл сертификата будет находиться в каталоге ssl.crt, его необходимо нам передать обратно на тот компьютер, с которого отправлялся запрос на сертификацию. Последнее, что необходимо сделать, - это настроить Apache для использования данного ключа. SSLCertificateFile /usr/local/etc/apache/ssl.crt/<filename>.crt SSLCertificateKeyFile /usr/local/etc/apache/ssl.key/<filename>.key Выполняется это двумя директивами конфигурационного файла (основного или виртуального хоста). Не забывайте, что после изменения данных директив необходим полный перезапуск Apache, выполнения команды apachectl restart недостаточно. Ну вот, теперь у нас есть собственный удостоверяющий центр, и при посещении корпоративных порталов браузеры больше не будут выдавать сообщения "системы безопасности" (которые особенно раздражают на смартфонах, где почему-то нет возможности сохранить сертификат непосредственно при подключении). Ограничиваются ли возможности CA только удостоверением сертификатов сайтов? Да нет, конечно же. В следующей статье мы рассмотрим, каким образом можно использовать SSL при подключении к стандартным почтовым сервисам - POP3 И IMAP. 1. Ачилов Р. Заменяем сервер MS Exchange. Установка Horde Groupware. //Системный администратор, No.9, 2009 г. - С. 42-47. 2. Apache2 с SSL/TLS. Шаг за шагом - http://www.ti.chernigov.ua/labs/ksm/apache_ssl/ssl.html 3. Основы работы с OpenSSL - http://www.nixp.ru/articles/openssl 4. Авторизация с помощью клиентских SSL-сертификатов - http://www.opennet.dev/base/sec/ssl_cert.txt.html 5. Настройка Apache + modssl для работы через https - http://www.opennet.dev/base/net/apache_mod_ssl.txt.html 6. Adding a Certificate to the Root Store of a Windows Mobile-based Device - http://technet.microsoft.com/en-us/library/cc182241.aspx Статью можно обсудить на Форуме журнала "Системный администратор" http://www.samag.ru/forum/

2.6, AdVv (??), 22:07, 21/04/2013 [^] [^^] [^^^] [ответить]	+/–
> Насколько я понял, даже самые простые сертификаты обеспечивают защиту вводимых > личных данных. Но все-таки какой лучше выбрать для простого электронного-магазина? Обычный сертификат на доменное имя. Можно на доменное имя+все поддомены, это иногда удобнее, но дороже. Уровень безопасности одинаковый у всех видов сертификатов.