Как установить самоподписанный SSL-сертификат: Часть 2

Часть 1 >>>

Часто используемые сокращения.

  • SSL - уровень защищенных сокетов (secure socket layer);
  • CA - удостоверяющий центр (center of authority);
  • CSR - запрос на сертификацию (certificate signing request);
  • CRL - список отозванных сертификатов (certificate revocation list);
  • PKCS - криптографические стандарты с открытым ключом (public-key cryptography standards);
  • CN - общие данные (common name).

Введение

Наиболее распространённой областью применения SSL-сертификатов является защита HTTP-трафика, для чего сертификат устанавливается на Web-сервер и используется для шифрования трафика между сервером и клиентом. Корпоративная почта и системы групповой работы, системы хранения документов и всевозможные Web-приложения - все они нуждаются в защите HTTP-трафика.

Поэтому защита внутренних ресурсов обычно начинается с внедрения корпоративных SSL-сертификатов. В данной статье описывается процесс установки сертификата для сайта, активации сертификата в Web-браузере клиента и ограничения круга пользователей, которым разрешается посещать Web-сайт.

Установка серверного сертификата

Для того, чтобы к Web-сайту можно было обращаться по протоколу HTTPS, на нем должен быть установлен собственный сертификат. "Собственный" означает, что имя сайта, используемое клиентами для обращения к сайту, совпадает с именем, указанным в поле CN сертификата. Однако, так как по требованиям протокола SSL комбинация "адрес:порт" должна быть уникальной, то установить несколько различных виртуальных серверов (с различными сертификатами) на один порт 443 не получится, и для каждого сервера потребуется выделить отдельный порт и указать его при описании данного сервера.

Процесс создания SSL-сертификата для сервера описывался в предыдущей части статьи. Поэтому предполагается, что серверный сертификат уже создан и подписан в корпоративном СА, а также имеются файлы myfile.key и myfile.crt, соответствующие ключу и сертификату сайта. Но до того, как клиенты Web-сайта смогут начать ими пользоваться, эти файлы потребуется подключить к Web-серверу (в рамках данной статьи используется Wеб-сервер Apache) через конфигурационный файл виртуального сервера (или корневого сайта) как показано в листинге 1:

Листинг 1. Подключение SSL-сертификатов
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite HIGH:MEDIUM:EXP:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM:+EXP
    SSLCertificateFile "/etc/ssl/certs/myfile.crt"
    SSLCertificateKeyFile "/etc/ssl/certs/myfile.key"

В листинге 1 приведены только параметры (директивы конфигурации Apache), относящиеся к SSL-сертификатам, поэтому для полноценной конфигурации потребуется указать и другие параметры. Указанные директивы записываются в блоке <VirtualHost> (для виртуального сервера) или в конфигурационном файле корневого сервера (для стандартного Web-сервера).

В данном примере выполняется включение SSL (1-ая строка), на 2-ой строке происходит отключение слабой и небезопасной версии 2.0 протокола SSL. Затем на 3-ей строке устанавливаются параметры защищенного соединения, которые могут использоваться (какой набор параметров будет выбран, зависит еще и от подключающегося клиента). На строках 4 и 5 указываются SSLCertificateFile и SSLCertificateKeyFile – пути к файлу c SSL-сертификатом и к файлу с ключом сертификата.

Для нормальной работы SSL необходимо, чтобы имя сервера, прописанное в директиве ServerName, совпадало с именем, указанным для поля CN в процессе создания сертификата. Если это правило не выполняется, то при обращении к сайту Web-браузер будет постоянно отображать страницу с предупреждением.

Важное примечание: проверяется именно директива ServerName, а не директива ServerAlias. Если для сервера необходимо указать несколько имен, то их можно прописать в директиве ServerAlias.


 

Установка сертификата в Web-браузер пользователя

Тем не менее при первой попытке войти на сайт, где установлен SSL-сертификат, подписанный корпоративным СА, все равно возникнет ошибка, так как Web-браузер будет утверждать, что возникла критическая ситуация и это поддельный сертификат. В Web-браузере Google Chrome будет отображена страница красного цвета во весь экран, а в Mozilla Firefox – желтого, при этом обе страницы будут предупреждать пользователя, что произошел критический сбой в системе безопасности, как показано на рисунках 1 и 2.

Рисунок 1. Отображение неизвестного сертификата в Google Chrome

Рисунок 1. Отображение неизвестного сертификата в Google Chrome

Рисунок 2. Отображение неизвестного сертификата в Mozilla Firefox

Рисунок 2. Отображение неизвестного сертификата в Mozilla Firefox

Web-браузеры выводят сообщения, изображенные на рисунках, так как не могут проверить, какая организация подписала данный сертификат. Как уже упоминалось в прошлой части, система CA – иерархическая, и сертификаты корневых СА распространяются вместе с Web-браузерами. В Google Chrome используется хранилище сертификатов Windows, и его список корневых сертификатов может измениться после установки пакета с обновлениями от Microsoft, а в Mozilla Firefox используется собственное хранилище сертификатов.

Поскольку данный сертификат подписан внутри самой организации, то её корневой сертификат у Web-браузера, конечно, отсутствует, и он считает, что произошла ошибка. Чтобы исправить эту ошибку, достаточно просто распространить на все компьютеры в локальной сети сертификат корпоративного СА (файл caserv.crt) ещё до того момента, как пользователи начнут обращаться к корпоративным Web-ресурсам по протоколу HTTPS. Этот сертификат потребуется установить в системное хранилище Windows и в хранилище Firefox (а если используется еще и Web-браузер Opera, то и в его собственное хранилище).

Процесс установки сертификата не представляет особой сложности, однако система несколько раз уточнит: действительно ли можно доверять этому издателю сертификатов. Также необходимо обратить внимание, куда именно будет установлен сертификат: он должен быть установлен в "Доверенные Корневые Центры Сертификации", а не в какую-либо другую группу.

Преобразование SSL-сертификата из одного формата в другой

Установка корневого сертификата на мобильное устройство (например, смартфон Nokia N95 8G) требует значительно больше усилий, так как смартфон не понимает текстовых сертификатов (формат PEM). Поэтому в данном разделе рассматривается процесс перекодирования сертификата из одного формата в другой.

Существуют два стандартных формата для хранения сертификатов - PEM (текстовый) и DER (двоичный). С точки зрения содержания они не отличаются друг от друга, но текстовый формат разработан так, чтобы его можно было просматривать в текстовых редакторах и без проблем пересылать по почте. Отличие между форматами состоит в степени их поддержки различными устройствами, так как формат PEM поддерживается далеко не всеми устройствами. Поэтому для установки корневого сертификата СА на устройство, которое не поддерживает формат PEM, его потребуется предварительно перекодировать.

Перекодирование сертификата из формата PEM в формат DER выполняется следующей командой:

# openssl x509 -in caserv.crt -out caserv.cer -inform PEM -outform DER

Расширение файла (.cer) – это стандартное расширение для сертификатов формата DER. Этот формат поддерживается большим числом оборудований, в частности, упомянутым выше смартфоном Nokia N95 8G. Обратное преобразование из формата DER в формат PEM выполняется сходным образом:

# openssl x509 -in caserv.cer -out caserv.crt -inform DER -outform PEM

Для обратного преобразования в команде достаточно просто поменять порядок аргументов, но полученный таким образом PEM-файл не будет содержать текстовой части (содержимое сертификата, пригодное для просмотра человеком), поэтому для создания сертификата с заполненной текстовой частью используется другая команда:

# openssl x509 -in caserv.crt -out caserv.pem -text

Если же, наоборот, необходимо удалить из сертификата текстовую часть, то используется следующая команда:

# openssl x509 -in caserv.pem -out caserv.crt

Сертификат корпоративного СА, перекодированный в формат DER, переносится на смартфон и устанавливается способом, специфичным для конкретного мобильного устройства.

Установка SSL-соединения с Web-сайтом

После того, как сертификат корпоративного СА установлен в качестве корневого, Web-браузеры распознают сертификаты, подписанные им, и больше не выводят страниц с предупреждениями, а сразу устанавливают соединение с запрошенным ресурсом, как показано ниже.

Рисунок 3. Установленное SSL-cоединение в Google Chrome

Рисунок 3. Установленное SSL-cоединение в Google Chrome

Рисунок 4. Установленное SSL-cоединение в Mozilla Firefox

Рисунок 4. Установленное SSL-cоединение в Mozilla Firefox

При выполнении подключения к Web-сайту с установленным SSL-сертификатом дополнительно могут проверяться следующие параметры: дата начала и окончания срока действия сертификата. Если дата начала срока действия еще не наступила или наоборот, дата окончания срока действия уже прошла, то сертификат, независимо от наличия установленного корневого сертификата CA, будет объявлен ошибочным.

Также может быть проверено, не отозван ли данный сертификат. Как было упомянуто в предыдущей статье, система должна иметь возможность блокировки сертификатов, которые были выданы людям, на данный момент покинувшим организацию. Поэтому в сертификат можно добавить параметры, которые будут распознаваться Web-браузерами. На основании полученной информации Web-браузер сможет загрузить с указанного адреса CRL и проверить, не входит ли сертификат, используемый для подключения, в список отозванных. Если этот сертификат присутствует в списке отозванных, то соединение будет заблокировано.

Важное примечание: ссылка на CRL должна указываться и в параметре CRLDistributionPoint (как определено в новой версии стандарта), так и в параметре nsCaRevocationList - именно этот параметр считывается многими Web-браузерами, и при его отсутствии возникают сообщения об отсутствующем списке CRL и т.д.

Ограничение возможности подключения для нежелательных клиентов

Посторонние пользователи не должны иметь доступ к корпоративной Intranet-сети - это совершенно очевидно. Поэтому, чтобы иметь возможность управлять клиентскими подключениями с помощью серверного SSL-сертификата, в конфигурационный файл виртуального сервера необходимо добавить строки, приведенные в листинге 2.

Листинг 2. Добавление ограничений на подключение клиентов
    SSLCertificateChainFile "/etc/ssl/rootca/caserv.crt"
    SSLCACertificateFile "/etc/ssl/rootca/caserv.crt"
    SSLCARevocationFile "/etc/ssl/rootca/cacrl.crl"
    SSLVerifyClient require

Параметры SSLCertificateChainFile и SSLCACertificateFile задают сертификат корпоративного СА, параметр SSLCARevocationFile определяет путь к CRL, а параметр SSLVerifyClient активирует проверку клиентского сертификата. В этом примере вводится самое простое ограничение: к сайту смогут подключиться только те пользователи, у которых на компьютерах установлен клиентский сертификат, подписанный корпоративным СА. При этом никаких дополнительных проверок выполняться не будет, если на клиентском компьютере, осуществляющем подключение к серверу, отсутствует клиентский сертификат, то в установке подключения будет отказано, как показано ниже.

Рисунок 5. Страница с сообщением об отказе в подключении в Google Chrome

Рисунок 5. Страница с сообщением об отказе в подключении в Google Chrome

Рисунок 6. Страница с сообщением об отказе в подключении в Mozilla Firefox

Рисунок 6. Страница с сообщением об отказе в подключении в Mozilla Firefox

Если простого условия о наличии SSL-сертификата, подписанного корпоративным СА недостаточно, то на основе параметра SSLRequire можно реализовать более сложные проверки, которые будут учитывать различные параметры сертификата.

Существует еще одна проблема, связанная с задачей организовать доступ к Web-ресурсу с контролем доступа по сертификатам, когда этот Web-сайт не обладает подобной функциональностью. Простым перенаправлением HTTP-запросов на страницу авторизации эту проблему не решить, так как клиент сможет заходить на Web-ресурс напрямую по его внутренним ссылкам, минуя страницу авторизации.

В данном случае может пригодиться такой прием, как «обратное проксирование», при котором, как и в случае обычного проксирования, есть некоторая программа, работающая на сервере и получающая запросы с одной стороны, а затем транслирующая их на другую. При этом достаточно установить защищенное соединение только с самим прокси-сервером, соединение между прокси-сервером и защищенным Web-сайтом может выполняться и без шифрования.

Заключение

C точки зрения организации безопасной ИТ-среды Web-ресурсы любой компании в первую очередь нуждаются в защите HTTP-трафика, причем, как правило, необходимо не только сгенерировать ключи для всех используемых серверов, но и организовать их разделение по портам, так как из-за требований протокола HTTPS на одном физическом сервере на одном и том же порту нельзя разместить несколько виртуальных Web-серверов с поддержкой HTTPS.

Дополнительно следует продумать вопрос, необходимо ли ограничить круг пользователей, которые будут иметь доступ к указанным Web-ресурсам. Если такая необходимость возникнет, то для всех пользователей потребуется сгенерировать клиентские SSL-сертификаты, обеспечить регулярное обновление CRL для отзыва аннулированных сертификатов и активировать поддержку CRL на Web-сайте, доступ к которому должен быть ограничен.

Часть 1 >>>

Источник: https://www.ibm.com/developerworks/ru/library/l-cerfiticate_management_02/