Ключевые слова:ssl, crypt, apache, mod_ssl, (найти похожие документы)
From: Sergei Karasiov <[email protected]>
Newsgroups: email
Date: Mon, 17 Sep 2003 14:31:37 +0000 (UTC)
Subject: Создание SSL сертификатов для связки Apache и mod_ssl
Исходник: http://slacksite.com/apache/certificate.html
Оригинал перевода: http://blog.spb.ru/apache_modssl.html
Перевод: Sergei Karasiov <[email protected]>
Создание SSL сертификатов для связки Apache и mod_ssl
Предисловие переводчика
Данный текст не является дословным переводом английского оригинала.
Это спровоцировано отчасти ленью переводчика, отчасти пробелами в его
(переводчика) образовании. Однако этот текст может послужить неплохим
пинком(starting point) для начала исследований не только модуля
mod_ssl, но и пакета openssl в целом. Тем более что за идеологическую
адекватность перевода я поручиться все же попытаюсь. Во всяком случае,
стиль и дух произведения я честно пытался сохранить.
Неплохо зная характер отечественного читателя, я могу предположить,
что некоторые очевидные подробности (такие, например, как рассказ про
переменную PATH ) могут разозлить и оскорбить потенциального
потребителя данного текста, который полагает себя вполне
профессионалом не нуждающимся в подобных подсказках. Однако, про стиль
и дух я сказал выше и более добавить ничего не могу.
Дополнения и конструктивная критика - приветствуются. Авторское право
на перевод принадлежит переводчику. Публикация этого текста разрешена
в любом виде, при условии, что данное предисловие не будет изъято из
публикуемого текста. Ссылка на автора перевода (как вы уже
догадались)при публикации обязательна.
СПБ-09-2003
Интродукция
Предполагается, что этот документ будет кратким пособием по генерации
и установке SSL сертификатов на сервер Apache с установленным модулем
mod_ssl. Хотя это не очень сложный процесс, он сопровождается запуском
нескольких длинных команд с большим количеством ключей. Этого
документа должно быть достаточно для того, чтобы вы могли
сгенерировать и установить сертификаты для вашего сервера.
Этот документ не предназначен для обсуждения процессов компиляции и
установки сервера Apache и модуля mod_ssl. Для подробных инструкций
смотрите "Сборка Apache с mod_ssl и другими модулями." - http://slacksite.com/apache/webserver.html
Так же этот документ не предназначен для подробного обсуждения конфигурирования
SSL на серверах Apache. Будут представлены примеры конфигурации
простого виртуального хоста с использованием SSL, который должен
работать в практически любой стандартной ситуации. Ralf Engelschall,
автор модуля mod_ssl, поддерживает замечательную документацию на
http://www.modssl.org. Для того чтобы более подробно узнать о
конфигурировании SSL или особых случаях смотрите полную документацию
на http://www.openssl.org/docs/. В дополнение дистрибутив содержит
подробные страницы мануалов, которые доступны так же и в формате HTML
на http://www.openssl.org/docs/.
Короткий рассказ об SSL
Эта глава будет очень коротким введением в SSL, Secure Socket Layer.
Криптография очень обширная тема, которая составляет буквально тома
материалов. Последующий материал . это очень упрощенный взгляд на то,
как реализован SSL и какую роль сертификаты играют в рассматриваемом
нами случае. В силу того, что информация намеренно упрощена, возможны
небольшие неточности.
Обычный веб-траффик идет через Интернет незашифрованным. Таким
образом, любой, кто имеет доступ к нужным инструментам, может
наблюдать за нужным ему трафиком. Очевидно, что это может привести к
проблемам, особенно в тех случаях, когда необходимы безопасность и
приватность, например при работе с кредитками или в банковских
транзакциях. Протокол SSL используется для шифрования трафика между
веб-сервером и веб-клиентом (браузером).
SSL использует асимметричную криптографию, обычно известную как
криптография с открытым ключом. В криптографии с открытым ключом
создаются два ключа, одни публичный . другой секретный. Все
зашифрованное с помощью одного ключа может быть расшифровано только с
помощью другого. То есть данные, которые были зашифрованы секретным
ключом сервера могут быть дешифрованы только с помощью публичного
ключа этого же сервера, давая уверенность что, данные пришли оттуда
откуда надо.
Если SSL использует криптографию с открытым ключом, для того чтобы
шифровать поток данных идущих через Интернет, зачем же тогда нужен
сертификат? Технический ответ на этот вопрос, такой, что сертификат на
самом деле не нужен . данные зашифрованы и вряд ли могут быть
дешифрованы третьей стороной. Однако сертификаты играют важную роль в
коммуникационном процессе. Сертификат, подписанный доверенным СА
(Certificate Authority), дает гарантию, что владелец сертификата . тот
за кого он себя выдает. Без подписанного сертификата ваши данные будут
зашифрованы, однако, сервер, с которым вы контактируете может быть не
тем о котором вы думаете. Без сертификатов такие нарушения могут быть
часты.
Генерация частного ключа и CSR
Программный пакет openssl может быть использован для генерации
приватного RSA ключа и создания CSR. Он так же может быть использован
для создания самоподписных сертификатов которые могут быть
использованы для тестовых целей или внутреннего пользования.
Программа, которая обычно используется для решения этих задач,
известна как openssl. Она должна быть установлена в директории
/usr/local/ssl. Может быть, вам придется добавить эту директорию в
переменную PATH или же переместить эту программу в директорию, которая
уже прописана в переменной PATH, для того чтобы не писать полный путь.
Дальнейшие примеры полагают, что openssl доступен вам без
необходимости писать полный путь.
В первую очередь надо создать ваш приватный ключ. Это будет 1024
битный ключ стандарта RSA зашифрованный с использованием алгоритма
TripleDES и хранящийся в формате PEM, так что его можно будет читать
как простой текст. Мы будем использовать несколько файлов для усиления
случайности и для того чтобы сделать наш ключ более секретным.
Текстовые файлы, которые были сжаты утилитой типа gzip . станут
хорошим выбором. Ключ генерируется следующей командой, где
file1:file2:etc представляют собой случайные сжатые файлы.
$ openssl genrsa -des3 -rand file1:file2:file3 -out server.key
Программа предложит вам ввести пароль и сохранит ключ в файле
server.key. Очень важно не забыть пароль. Если ключ будет утерян или
пароль будет забыт сертификат станет бесполезен. Невозможно выразить
как важен приватный ключ для сертификата. Если приватный ключ или
пароль скомпрометированы сертификат должен быть отменен. Как минимум
это будет стоить вам денег заплаченных за сертификат. Было бы хорошей
идеей сделать резервную копию на безопасном носителе, таком как
кассета или дискета.
Один неприятный сторонний эффект ключа с паролем это то что Apache
будет всякий раз спрашивать пароль при старте. Понятно что это не
очень удобно если только кто-то не находится постоянно рядом на случай
перезагрузки или аварийной остановки. mod_ssl включает в себя
возможность использования внешней программы вместо встроенного
парольного диалога. Возможно убрать пароль из ключа. Если приватный
ключ более не зашифрован, важно чтобы файл его содержащий, был
доступен на чтение только пользователю root. Если ваша система
скомпрометирована и третья сторона получила ваш незашифрованный
приватный ключ, производный сертификат должен быть отменен. После того
что мы сказали, используйте следующую команду для того чтобы убрать
пароль из ключа.
$ openssl rsa -in server.key -out server.pem
После того как приватный ключ сгенерирован может быть сгенерирован
запрос на подпись сертификатов(CSR ---). CSR может быть использован
двояко. В идеале CSR должен быть послан к CA такому как Tawte или
VeriSign, которые проверят подлинность запрашивающего и выдадут
подписанный сертификат. Другой путь - подписать CSR самостоятельно,
что будет продемонстрировано в следующей главе.
Во время генерации CSR вас попросят ввести некоторое количество
информации. Один из вопросов будет Common Name (eg, YOUR name) []:
Важно чтобы это поле содержало полностью квалифицированное имя домена
вашего сервера. Если вебсайт имеет адрес www.domain.com- то вы должны
написать именно www.domain.com. Команда для генерации CSR выглядит
так.
$ openssl req -new -key server.key -out server.csr
Пример сессии показан ниже.
$ openssl req -new -key server.key -out server.csr
Using configuration from /usr/local/ssl/openssl.cnf
Enter PEM pass phrase:Enter pass phrase here
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New Hampshire
Locality Name (eg, city) []:Nashua
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Domain.com, Inc.
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:www.domain.com
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Генерация самоподписанного сертификата
На этом этапе вам необходимо сгенерировать самоподписанный сертификат
потому что вы или не планируете заводить сертификат подписанный CA,
или хотите потестировать новую реализацию SSL пока CA подписывает ваш
сертификат. Мой опыт общения с Tawte показывает, что получение
сертификата занимает неделю и больше. Время которое занимает получение
сертификата варьируется от того как быстро CA получит необходимые
документы. Временный сертификат будет выдавать ошибку в клиентском
броузере от того, что CA неизвестен и не проверен.
Для того чтобы сгенерировать сертификат годный в течение 60 дней
введите следующую команду.
$ openssl x509 -req -days 60 -in server.csr -signkey server.key -out server.crt
Установка ключа и сертификата
Когда Apache и mod_ssl установлены - создаются несколько поддиректорий
в конфигурационной директории Apache. Их расположение зависит от того,
как компилировался Apache. Если использовать мои инструкции,
компилируя Apache, конфигурационная директория будет
/usr/local/apache/etc Директории, которые создает mod_ssl содержат в
себе файлы ssl.crt, ssl.csr, и ssl.key Это хорошее место для хранения
сертификатов, запросов на подпись и приватных ключей. Если у вас будет
несколько хостов с SSL хорошей практикой стать включение в имена этих
файлов имен защищаемых хостов.
Добавляя виртуальные хосты к веб-серверу, я обычно предпочитаю хранить
их конфигурации в отдельном файле. Это дает уверенность, что все
конфигурации могут быть быстро найдены, и, заодно, не позволяет
основному конфигурационному файлу разрастаться. Если все виртуальные
хосты сохранены в файле ssl.conf, то для того чтобы Apache нашел его и
прочитал надо включить в основной конфиг следующюю строку:
Include /usr/local/apache/etc/ssl.conf
Конфигурирование виртуального хоста, использующего SSL.
Обширные примеры конфигурации SSL для виртуальных хостов включены в
файл /usr/local/apache/etc/httpd.conf.default, который устанавливается
вместе с mod_ssl. Ознакомьтесь с документацией на mod_ssl для того
чтобы получить более подробную информацию о возможностях конфигурации.
Простой хост использующий SSL в конфигурационном файле может быть
прописан так. SSL Virtual Hosts
<IfDefine SSL>
<VirtualHost _default_:443>
ServerAdmin [email protected]
DocumentRoot /usr/local/apache/share/htdocs
ServerName www.domain.com
ScriptAlias /cgi-bin/ /usr/local/apache/share/htdocs/cgi-bin/
SSLEngine on
SSLCertificateFile /usr/local/apache/etc/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/etc/ssl.key/server.pem
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog /usr/local/apache/var/log/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
<VirtualHost>
<IfDefine>
Этот пример создаст виртуальный хост с именем. который доступен через
порт 443 (стандартный порт для протокола https) сайты с IP адресом
вашего сервера. Можно создать столько дополнительных виртуальных
хостов для вашего сервера сколько IP адресов он обслуживает. Просто
добавьте дополнительные конфигурационные блоки <virtualhost> между
дерективами <IfDefine SSL> и </IfDefine>. По архитектурным причинам
протокол SSL не позволяет создавать name-based (HTTPS 1.1) виртуальные
хосты. Для того чтобы создать новый виртуальный хост с поддержкой SSL
на другом IP адресе просто замените _default_на новый IP.
Посте добавления виртуального хоста к конфигурационному файлу Apache
должен быть остановлен и вновь запущен для того чтобы новый
виртуальный хост заработал. К несчастью это один из тех случаев когда
простая отправка сигнала HUP не сработает. После перезапуска в
зависимости от того какой (шифрованный или нет ) ключ был использован
Apache может спросить у вас пароль или пароли. Введите пароль, и всё
заработает.
Теперь вы можете использовать ваш любимый броузер для просмотра
содержимого только что созданного виртуального хоста защищённого SSL .
Не забудьте использовать префикс https:// вместо http://. Вы получите
окно с предупреждением, если вы использовали самоподписанный
сертификат. Подтвердите согласие и страница продолжит загружаться уже
защищенная с помощью SSL . Статусная строка вашего броузера должна
содержать иконку в виде замка которая показывает что страница
защищена. Вот и всё.
То есть данные, которые были зашифрованы секретным
ключом сервера могут быть дешифрованы только с помощью публичного
ключа этого же сервера, давая уверенность что, данные пришли оттуда
откуда надо.
А не наоборот? Шифруют публичным, а дешифруют секретным?
по моему работают оба ключа.
если данные идут от сервера к клиенту, то шифрует секретный, расшифровывает открытый.
если от клиента к серверу, то шифрует открытый, расшифровывает закрытый
Вы оба не правы.
Точней сказать не полностью правы.
Секретный ключ нужен для подписания и дешифрования.
Публичный - для шифрования и проверки подписи.
Объясню: у меня есть пара ключей. Использую для почты.
Я написал кому-нибудь письмо. Далее, если у получателя (того кому я пишу письмо) есть пара ключей (соответственно у меня есть его публичный ключ), подписываю своим закрытым ключом и шифрую письмо публичным ключом получателя.
Получатель получает письмо, у него есть мой публичный ключ и свой секретный - расшифровывает письмо своим закрытым ключом и проверяет мою подпись при помощи моего публичного ключа.