Содержание


SSL-сертификаты Web-сайтов и их применение

Часть 1.Создание центра сертификации и операции с сертификатами

Comments

Серия контента:

Этот контент является частью # из серии # статей: SSL-сертификаты Web-сайтов и их применение

Следите за выходом новых статей этой серии.

Этот контент является частью серии:SSL-сертификаты Web-сайтов и их применение

Следите за выходом новых статей этой серии.

Трудно переоценить роль защищенных коммуникаций в функционировании сети Интернет. Электронные платежи, защищенная почта и многие другие технологии - это далеко не полный перечень того, где с момента создания используется протокол SSL, разработанный еще в 1995 году, но только в 1999 признанный стандартом и определенный в RFC2246.

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

Назначение SSL-сертификатов

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

Эта система похожа на DNS: точно также существует набор некоторых "удостоверяющих" центров (называемых центрами сертификации - CA), и, если сертификат подписан ключом одного из этих центров, информация в нем считается верной. Эта услуга является платной, так годовая лицензия VeriSign (одного из наиболее авторитетных CA) стоит $1200. Если сертификат сайта подписан каким-либо известным CA, то достоверность адреса подтверждается авторитетом СА, подписавшего сертификат. Однако при развертывании защищенной корпоративной сети, для которой потребуется выдать несколько десятков сертификатов, использование стороннего CA потребует дополнительных расходов, и более выгодно будет создать собственный СА.

После создания собственного CA внутри компании появится единый центр, подпись которого на сертификате будет иметь ту же силу, что и подпись VeriSign, но в масштабах компании. Для этого достаточно распространить на все компьютеры и мобильные устройства собственный сертификат «родного» CA, объявив его корневым, и все ключи, которые были или будут в будущем подписаны им, автоматически станут «безопасными», поскольку их принадлежность может быть проверена. Это также даст возможность создавать списки отозванных сертификатов, которые будут автоматически проверяться при установлении защищенного соединения.

VeriSign собственного изготовления

В общем случае процедура выглядит так: клиент, желающий получить сертификат, генерирует CSR (при этом также создается ключ сертификата) и отправляет CSR в CA. СА получает CSR, подписывает его и создает собственно сертификат, который отправляется обратно клиенту. Возможен и другой вариант: клиенту сразу генерируется ключ сертификата, сертификат, и все это вместе с сертификатом СА упаковывается в файл формата PKCS#12 (расширение .p12), защищается паролем и отправляется клиенту.

При создании собственного СА потребуется создать структуру каталогов для хранения следующих данных:

  • принятые запросы на сертификацию (CSR);
  • подписанные сертификаты (CRT);
  • список отозванных сертификатов (CRL);
  • закрытый ключ собственного сертификата CA.

В листинге 1 показана структура каталогов, созданная модулем apache1 mod_ssl, но можно использовать и произвольные названия.

Листинг 1. Создание каталогов для СА
# cd /etc/ssl/corpca
# mkdir ssl.crl
# mkdir ssl.crt
# mkdir ssl.csr
# mkdir ssl.key
# mkdir ssl.prm

После создания необходимых каталогов потребуется внести изменения в конфигурационный файл OpenSSL. В листинге 2 показаны три фрагмента файла openssl.cnf: стандартный CA_default и два добавленных раздела ssl_server и ssl_client.

Листинг 2. Фрагменты конфигурационного файла openssl.cnf
[ CA_default ]
dir             = .                       # корневой каталог CA
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/cacrl.pem          # актуальный список отозванных сертификатов
private_key     = $dir/ssl.key/caserv.key # закрытый ключ
RANDFILE        = $dir/ssl.key/.rand      # файл закрытого генератора случайных чисел
x509_extensions = usr_cert                # расширения, добавляемые к сертификату
name_opt        = ca_default            # параметры поля Subject Name
cert_opt        = ca_default            # параметры поля Certificate
default_days    = 365                   # период действия сертификатов
default_crl_days= 30                    # период обновления CRL
default_md      = md5                   # используемый алгоритм
preserve        = no
policy          = policy_match
[ ssl_server ]
basicConstraints        = CA:FALSE
nsCertType              = server, email
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = serverAuth, nsSGC, msSGC, emailProtection
nsComment               = "OpenSSL Certificate for SSL Web Server"
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer:always
subjectAltName          = email:copy
issuerAltName           = issuer:copy
crlDistributionPoints   = URI:http://certmgr.askd.ru/certs/cacrl.pem
[ ssl_client ]
basicConstraints        = CA:FALSE
nsCertType              = client, email
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = clientAuth, emailProtection
nsComment               = "OpenSSL Certificate for SSL Client"
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer:always
subjectAltName          = email:copy
crlDistributionPoints   = URI:http://certmgr.askd.ru/certs/cacrl.pem
issuerAltName           = issuer:copy

В листинге 2, кроме установки путей по умолчанию, добавляются две новые секции - [ssl_server] и [ssl_client], где указываются параметры сертификата в зависимости от режима работы программы, которая будет его использовать. Web-сервера и почтовые сервера предполагают наличие серверного сертификата, а клиенты электронной почты - наоборот, клиентского.

Установка параметров в секциях [ssl_server] и [ssl_client] производится в соответствии с man x509v3_config. При использовании параметра crlDistributionPoints его значение должно содержать общедоступную ссылку на CRL данного CA. CRL будет использоваться программами, имеющими такую возможность (например, Web-браузерами) для проверки списка отозванных сертификатов, и при попытке использования отозванного сертификата соединение установлено не будет, вместо этого будет выдано сообщение об ошибке.

В листинге 2 имя файла с сертификатом СА - caserv.crt, имя файла с ключом сертификата СА - caserv.key и имя файла с CRL - cacrl.pem. Программы, не умеющие использовать файл CRL, используют так называемый файл MCF (merged control file - объединенный контрольный файл), представляющий собой просто идущие подряд сертификат и CRL для данного CA. MCF-файл создается командой cat, как показано ниже:

# cd /etc/ssl/corpca
# cat caserv.crt cacrl.pem > camerged.pem

После внесения изменений в конфигурационный файл необходимо создать главный сертификат CA, которым будут подписываться все остальные сертификаты. Процесс создания показан в листинге 3:

Листинг 3. Создание главного сертификата СА
# openssl req	-config /etc/ssl/openssl.cnf -new -newkey rsa:1024 \ 
-keyout caserv.key -x509 -days 7300 -out caserv.crt

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) []:IT department
Common Name (eg, YOUR name) []:bigcat.sheltonsoft.ru
Email Address []:root@sheltonsoft.ru

При задании пароля следует указать пароль, длиной не менее 12 символов, так как если произойдет утечка ключа и сертификата, то надежность всего СА будет зависеть от «криптоустойчивости» этого пароля. Остальная информация будет отображаться при просмотре сертификата как данные об удостоверяющем центре. Сертификат создается в формате RSA длиной 1024 бита и будет считаться действительным 10 лет. Срок действия сертификата CA – это один из основных параметров, так как, когда он закончится, основной сертификат автоматически исчезнет из списков "доверенных", а за ним и все подписанные им сертификаты.

После создания файл caserv.key следует поместить в каталог ssl.key, установить полномочия 0400 и защитить его от несанкционированного доступа. Файл caserv.crt, наоборот, следует сделать общедоступным и установить в качестве корневого сертификата на все устройства, которые будут обращаться к ресурсам корпоративной сети.

Также потребуется создать индексный файл базы данных с подписанными сертификатами (название этого файла задается в параметре database секции [CA_default]) и файл с текущим серийным номером (название этого файла задается в параметре serial секции [CA_default]). В листинге 4 показаны команды для создания двух этих файлов.

Листинг 4. Создание индексного файла и файла текущего серийного номера СА
# cd /etc/ssl/corpca
# touch index.txt
# echo '01' > serial

После этих действий созданный CA готов к подписанию сертификатов.

Создание сертификатов

Первый способ создания сертификата используется, когда есть возможность создать CSR непосредственно на машине клиента - это, как правило, компьютеры под управлением UNIX или Linux. В листинге 5 приведены команды для создания CSR.

Листинг 5. Создание CSR непосредственно на клиентском компьютере
 # openssl req	-new -sha1 -newkey rsa:1024 -nodes -keyout myfile.key \
-out myfile.pem -config /etc/ssl/openssl.cnf
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Novosibirskaya oblast'
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 []:

В листинге 5 создается новый CSR, который будет записан в файл myfile.pem, и RSA-ключ сертификата, длиной 1024 бита. Контрольная сумма CSR рассчитывается с применением алгоритма SHA1. Наиболее значимым параметром является параметр -nodes, означающий, что ключ не будет защищаться паролем (сертификаты серверов обычно загружаются при запуске соответствующих программ, а запрос пароля может остановить процесс запуска). Во время создания CSR будет задано множество вопросов, ответы на которые будут занесены в CSR и впоследствии использоваться.

Особое внимание следует уделить заполнению поля Common Name (CN). На значение этого поля не накладывается никаких ограничений, однако оно должно «иметь смысл» для пользователей этого сертификата. Для Web-сервера это будет имя сайта, для сертификата электронной почты - имя человека, которому принадлежит этот адрес.

Сгенерированный CSR-файл myfile.pem необходимо передать на сервер, где установлен СА, и поместить в подкаталог ssl.csr. После этого можно выполнить подписание сертификата, как показано в листинге 6.

Листинг 6. Подпись клиентского сертификата клиента в собственном СА
# cd /etc/ssl/corpca
# openssl ca	-config /etc/ssl/openssl.cnf -policy policy_anything \
	-extensions ssl_server -out ssl.crt/myfile.pem -in ssl.csr/myfile.pem
# openssl x509 -in ssl.crt/myfile.pem -out ssl.crt/myfile.crt

Для сертификата сервера в параметре -extensions указывается имя секции ssl_server, а для сертификата клиента - ssl_client. Создается сразу два варианта сертификата: с текстовой частью - myfile.pem и без текстовой части - myfile.crt, при этом сертификат в одном формате можно перевести в другой формат. Для подписания сертификата потребуется ввести пароль от главного сертфиката СА. После подписания любой готовый сертификат (или оба) можно отправить обратно клиенту для использования в программах.

Второй способ создания сертификатов используется тогда, когда создать CSR непосредственно на клиентском компьютере невозможно (не-UNIX системы, мобильные устройства, разнообразное сетевое оборудование). В этом случае на компьютере с установленным СА создается CSR, и подписывается сертификат (команды создания CSR и подписи сертификата идентичны приведенным выше, только в параметре -extensions используется имя секции ssl_client). После создания сертификата все созданные файлы плюс сертификат самого СА собираются в архив формата PKCS#12 и передаются клиенту. Это самое уязвимое с точки зрения безопасности место: передается сертификат вместе с ключом, а защищен архив только паролем! Команда для создания архива PKCS#12 приведена в листинге 7:

Листинг 7. Создание архива PKCS#12
# cd /etc/ssl/corpca
# openssl pkcs12	-export -in myfile.crt -inkey myfile.key -certfile caserv.crt \
			-out myfile.p12 -passout pass:123456

В листинге 7 создается архив myfile.p12 c паролем 123456, содержащий сертификат myfile.crt, ключ сертификата myfile.key и ключ СА caserv.crt. Этот архив передается клиенту и устанавливается средствами ОС клиента.

Отзыв сертификатов. Списки отозванных сертификатов

Как и в случае с любыми другими удостоверяющими документами, кроме возможности выдать сертификат, должна быть возможность прекратить его действие. Прекращение действия сертификата называется его отзывом, и в каждый момент времени существует файл, называемый списком отозванных сертификатов (CRL) с перечнем сертификатов, действие которых прекращено. Ссылка на этот файл может быть вставлена непосредственно в сертификат (параметр crlDistributionPoint в секциях ssl_server и ssl_client), кроме того, многим программам необходимо задавать ссылку на список отзыва или MCF в явном виде.

Необходимо учесть, что сама по себе операция отзыва не создает и не обновляет этот список, так как она только производит необходимые операции в индексном файле, указанном в параметре database секции CA_default. А для обновления списка потребуется выполнить отдельное действие. Отзыв сертификата выполняется способом, показанным ниже:

# cd /etc/ssl/corpca
# openssl ca	-config /etc/ssl/openssl.cnf -crl_reason <reason> \ 
-revoke ssl.crt/myfile.pem

В данном примере отзываемый сертификат находится в файле myfile.pem среди других сертификатов, подписанных СА. В качестве причины отзыва (crl_reason) можно указать следующие значения:

  • unspecified - этот вариант используется, когда значение параметра указано неверно или же опущено;
  • keycompromise, cacompromise/ - компроментация ключа или СА;
  • affilationchanged - переход в другой СА;
  • superseded - замена сертификата (например, после истечения срока действия);
  • cessationofoperation - прекращение обслуживания.

После отзыва сертификата необходимо обновить список отозванных сертификатов, или создать его, если не было еще ни одного отзыва, как показано ниже:

  # cd /etc/ssl/corpca
  # openssl ca -gencrl -out cacrl.pem

В результате в файле cacrl.pem создается список отозванных сертификатов. После создания CRL его можно обьединить с сертификатом СА для использования в программах, не имеющих отдельной настройки для CRL, а также сделать доступным по адресу, указанному в crlDistributionPoint. Хотя указание crlDistributionPoint – это не обязательное требование, оно оказывается очень полезным. Каждый раз при установлении защищенного соединения Web-браузер самостоятельно обратится по адресу, указанному в crlDistributionPoint, загрузит соответствующий файл и проверит, не входит ли сертификат данного узла (сайта) в список отозванных сертификатов. Если входит, то соединение установлено не будет. Также потребуется обновить все списки доступа и MCF для программ.

Заключение

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


Ресурсы для скачивания


Похожие темы

  • SSL-сертификаты Web-сайтов и их применение. Часть 1.

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=646537
ArticleTitle=SSL-сертификаты Web-сайтов и их применение: Часть 1.Создание центра сертификации и операции с сертификатами
publish-date=04122011