OS: Linux Debian/Ubuntu.
Application: OpenSSL, Nginx, Apache2.
Здесь простейшая шпаргалка процедуры подготовки к приобретению SSL/TLS-сертификата, проверки его корректности и применения в web-сервисе, расширенная некоторыми пояснениями.
Генерируем закрытый и открытый ключи.
Работы с компонентами сертификата очень желательно проводить в месте, закрытом от доступа посторонних:
$ mkdir -p ./make-cert
Прежде всего необходимо создать "закрытый" (он же "приватный") и "открытый" (он же "публичный") RSA-ключи шифрования, которые в дальнейшем будут использоваться при создании всех остальных компонентов сертификата и подтверждения подлинности такового на стороне web-сервера:
$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048
Мешанина символов, которую мы видим в текстовом файле ключей на самом деле представляет собой контейнер обфусцированного набора блоков сгенерированных в соответствии с алгоритмом RSA уникальных шифров, и один из этих блоков - "modulus" - является "открытым" ключём связки асимметричного шифрования, используемым во всех компонентах сертификата. Всё остальное содержимое - "закрытый" ключ.
Для ознакомления с содержимым блоков контейнера ключей его код можно раскрыть в более структурированном виде:
$ openssl rsa -noout -text -in ./example.net.key
Ключ (закрытый) шифрования по определению самое секретное, что есть в компонентах SSL-сертификата - потому по умолчанию он защищается паролем. Обязательно запоминаем введённый по запросу утилиты генерации пароль, он нам понадобится.
Надо отметить, что на практике, когда SSL-сертфикат применяется всего лишь для перевода на HTTPS ряда сайтов, большинство предпочитает не возиться с запароленным контейнером ключей, а сразу освобождает его от этой защиты, создавая рядом ещё один - "беспарольный":
$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt
Создаем запрос на выпуск X.509-сертификата (CSR).
Сама по себе подсистема защиты потока трафика посредством SSL/TLS обычно реализуется на сессионных симметричных ключах, вырабатываемых web-сервером и браузером клиента при первичном согласовании соединения, и какие-то особые предустановленные ключи шифрования для этого не требуются (хотя и облегчают процедуру согласования - DH-key, например). Сертификат же (стандарта X.509), набор компонентов которого мы здесь поэтапно формируем, предназначен для своего рода подтверждения подлинности web-ресурса в интернет-инфраструктуре, где условно доверенный центр сертификации гарантирует связь указанных в сертификате "открытого" ключа и описания ресурса посредством электронной подписи содержимого такового.
Для передачи центру сертификации нашего "публичного" ключа (не всего содержимого "приватного" ключа, а лишь его блока "modulus"!) и сведений о ресурсе, подлинность которого мы подтверждаем, предназначен специальный CSR-контейнер (Certificate Signing Request). Создаём его, указывая в качестве источника "открытого" ключа контейнер таковых:
$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr
В процессе потребуется указать данные о собственнике ресурса, для которого запрашивается сертификат, такие как:
"Country Name" - двухсимвольный код страны согласно ISO-3166 (RU - для России);
"State or Province Name" - название области или региона;
"Locality Name" - название города или населённого пункта;
"Organization Name" - название организации;
"Organizational Unit Name" - название подразделения (необязательное поле);
"Common Name" - полностью определённое доменное имя ресурса (FQDN), для которого запрашивается сертификат;
"Email Address" - контактный e-mail адрес администратора доменного имени (необязательное поле);
"A challenge password" - (необязательное поле, не заполняется);
"An optional company name" - альтернативное имя компании (необязательное поле, не заполняется).
Обращаю внимание, что если действие сертификата должно распространяться на поддомены удостоверяемого ресурса, то FQDN в поле "Common Name" потребуется дополнить маской "*." ("*.example.net" - например).
Любопытствующие могут посмотреть, что скрыто в коде CSR-контейнера:
$ openssl req -noout -text -in ./example.net.csr
CSR-файл "example.net.csr" отправляем в удостоверяющий центр, у которого мы приобретаем сертификат.
Приобретение SSL/TLS-сертификата (X.509).
Нюансы выбора поставщика сертификата, процедуры оформления заказа и оплаты здесь не рассматриваются, это не технический вопрос. Один из немаловажных моментов - не пропустить выбор между сертификатом предназначенным для одного домена и "wildcard", покрывающий своими гарантиями все поддомены следующего уровня.
Генерирование самоподписанного X.509-сертификата (опционально).
Как вариант, для использования исключительно в локальной сети, можно создать требуемый сертификат самостоятельно, подписав его своим "закрытым" ключём вместо доверенного центра сертификации - так называемый "self-signed" (самоподписанный):
$ cd ./make-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt
В результате работы вышеприведённой команды в дополнение к имеющимся компонентам мы получим файл "example.net.crt" самодельного сертификата, подлинность которого нельзя проверить в интернет инфраструктуре центров сертификации, хотя функционально он нормален и применим.
Проверка корректности сертификатов и ключей.
В полученном SSL/TLS-сертификате зафиксирована как минимум следующая информация:
Версия сертификата;
Серийный номер сертификата;
Алгоритм подписи;
Полное (уникальное) имя владельца сертификата;
Открытый ключ владельца сертификата;
Дата выдачи сертификата;
Дата окончания действия сертификата;
Полное (уникальное) имя центра сертификации;
Цифровая подпись издателя.
Лично я всегда проверяю верность указанных в сертификате данных, декодируя и просматривая его содержимое с помощью следующей команды:
$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt
На практике часто случается так, что некомпетентные клиенты или коллеги предоставляют для применения непосредственно в web-сервисах перепутанные сертификаты и ключи, не связанные между собой. Попытка применения таковых в web-сервере вызовет ошибку вроде "x509 key value mismatch".
Простейший способ проверки корректности связки "приватного" ключа, CSR-запроса и финального X.509-сертификата заключается в сверке контрольной суммы "публичного" ключа (блока "modulus"), содержащегося во всех этих контейнерах:
$ openssl rsa -noout -modulus -in ./example.net.key | openssl md5
$ openssl req -noout -modulus -in ./example.net.csr | openssl md5
$ openssl x509 -noout -modulus -in ./example.net.crt | openssl md5
Строка MD5-хеша короткая, и выявление различий между ними не составит труда.
Формируем типовой набор файлов сертификатов и ключей.
Обычно центры сертификации предоставляют не только запрашиваемый сертификат, а ещё и дополнительный набор промежуточных сертификатов (самого центра, его вышестоящего узла, и так вплоть до корневого узла).
В общем, в процессе у нас может скопиться несколько файлов, которые я именую соответственно их функционалу, примерно так:
"example.net.key" - контейнер с "закрытым" и "открытым" ключами (защищённый паролем);
"example.net.key.decrypt" - незащищённый паролем контейнер с "закрытым" и "открытым" ключами;
"example.net.csr" - CSR-запрос, использовавшийся при заказе сертификата;
"example.net.crt" - непосредственно наш X.509-сертификат;
"intermediate.crt" - сертификат (или цепочка таковых) центра сертификации;
"root.crt" - сертификат корневого центра, от которого начинается цепь доверия.
Промежуточные сертификаты нам предоставлены не только для ознакомления - ими желательно дополнить предназначенный для применения в web-сервисе контейнер с нашим сертификатом, сформировав там цепочку вплоть до общеизвестного доверенного узла. Делается это простейшим добавлением текстовых кодов в конец файла:
$ cd ./make-cert
$ cat ./example.net.crt >> ./example.net-chain.crt
$ сat ./intermediate.crt >> ./example.net-chain.crt
$ cat ./root.crt >> ./example.net-chain.crt
Обращаю внимание, что наш сертификат обязательно должен быть в начале цепочки, размещённой в контейнере - обычно web-сервер сверяет прилагаемый "закрытый" ключ с "открытым" в первом попавшемся в процессе чтения содержимого контейнера сертификате.
В Linux-е для сертификатов и ключей шифрования уже предусмотрены места в файловой системе. Распределяем файлы и защищаем их от доступа посторонних:
# mkdir -p /etc/ssl/certs
# mkdir -p /etc/ssl/private
# cp ./example.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/
# chown -R root:root /etc/ssl
# chmod -R o-rwx /etc/ssl
SSL-сертификат в web-сервере Nginx.
В самом простом случае применение SSL-сертификата в web-сервере "Nginx" реализуется примерно следующим образом:
# vi /etc/nginx/sites-enabled/example.net.conf
....
server {
listen 443 ssl;
server_name example.net;
....
ssl on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
ssl_certificate /etc/ssl/certs/example.net-chain.crt;
ssl_certificate_key /etc/ssl/private/example.net.key.decrypt;
....
}
....
SSL-сертификат в web-сервере Apache.
В web-сервере "Apache" SSL-сертификат применяется примерно так:
# vi /etc/apache2/sites-enabled/example.net.conf
....
# Описание рабочего окружения доступного по HTTPS web-сайта
ServerName example.net
....
# Рекомендуемые обобщённые настройки протокола
SSLEngine on
SSLProtocol all -SSLv2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
SSLCompression off
# Файлы сертификатов и ключей
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt
....
Существуют два вида криптографических систем: системы с секретным ключом (симметричные) и системы с открытым ключом (несимметричные). Говоря достаточно грубо, но понятно, симметричные системы используют один и тот же ключ для проведения операций шифрования и расшифровки, а несимметричные системы — разные.
В симметричных системах существует проблема распределения секретного ключа защищенным способом: обе стороны, обменивающиеся информацией, должны знать этот ключ, но никто другой этим ключом обладать не должен.
Несимметричные системы устроены так, что в них существует два числа:
- «открытый ключ пользователя A», который используется для зашифрования сообщения, предназначенного пользователю A,
- «закрытый ключ пользователя A», который используется этим пользователем для расшифровки направленных ему сообщений.
Последнее обстоятельство очень важно: пользователь может публиковать свой открытый ключ в общедоступных местах, чтобы любой мог им воспользоваться и зашифровать сообщение для A. Поэтому проблема распределения секретного ключа исчезает.
Пользователь должен держать свой закрытый ключ в секрете от посторонних: хочется, чтобы только пользователь мог расшифровывать сообщения, которые ему были направлены. Более того, требование секретности закрытого ключа очень важно в связи с понятием цифровой подписи, которая обсуждается немного ниже. Забегая вперед, скажем, что секретность закрытого ключа важна и потому что только пользователь должен иметь возможность создавать свою цифровую подпись, которая зависит от значения закрытого ключа.
Достаточно часто закрытый ключ хранится на носителе в зашифрованном виде и расшифровывается только на время произведения каких-то действий, требующих знания закрытого ключа. Это несколько повышает надежность хранения закрытого ключа, но создает неудобство, если закрытый ключ нужен какому-то автоматическому сервису: (как минимум) при каждом запуске этого сервиса нужно вводить пароль для расшифровки ключа.
Еще существуют смарт-карты, которые умеют производить криптографические операции внутри себя, отдавая на выход только результат, но не раскрывая содержимого закрытого ключа. Выкрасть закрытый ключ с правильно реализованной смарт-карты должно быть очень сложно. Закрытый ключ, даже хранящийся на смарт-карте, может быть защищен паролем. Если пароля нет, то любой, кто имеет смарт-карту у себя в руках, может произвести действия, для которых нужно знание закрытого ключа: значение самого закрытого ключа останется секретом, но будет возможнось производить с ним любые предусмотренные действия.
Цифровая подпись
У систем с открытым ключом есть еще одна приятная возможность: пользователь может создавать цифровую подпись, которая будучи поставлена на цифровом документе, может служить гарантией того, что пользователь, а не кто-то другой действительно подписал этот документ.
Схема концептуально проста: пользователь A, используя свой закрытый ключ, производит некоторую операцию над данными, которые он хочет подписать и передает результат вместе с исходными данными любому другому объекту. И этот самый объект, используя только открытый ключ пользователя A, может легко убедиться, что цифровая подпись верна.
Еще раз подчеркнем, что условие доступности данного закрытого ключа только его владельцу, играет очень важную роль: если оно выполняется, то пользователь не может отказаться от своей цифровой подписи. Это называется non-repudiation.
Одно из применений цифровой подписи — аутентификация объекта. Аутентификация — это процесс установления «личности» объекта. Понятно, что если объект может поставить цифровую подпись, то эта подпись может быть проверена, а объект связан со своим открытым ключом. Последний ингридиент, которого не хватает в этой схеме для аутентификации — это момент связывания открытого ключа и самого объекта: мы должны точно знать, кто именно владеет этим открытым ключом.
Удостоверяющий центр (Certification Authority)
Проблема связывания открытого ключа и некоего объекта может решаться разными способами. Один из самых простых подходов — это составить список соответствия открытых ключей и »имен« объектов. В качестве имени может выступать любой идентификатор, например доменное имя машины, полные имя, фамилия и отчество человека и т.д.; проблема уникальности имен, которая обязательно должна появляется — это отдельная трудность, которая обычно решается административными способами типа иерархической системы пространства имен и некоторой системы разрешения конфликтов имен внутри одного подпространства имен. Здесь эта проблема более освещаться не будет.
Но подход, основанный на списке соответствий, имеет очень слабое масштабирование, поскольку эти самые списки должны быть синхронизированы повсюду в мире (вернее, в той части мира, где эти списки используются).
Поэтому были введены понятия X.509-сертификата и удостоверяющего центра. X.509-сертификат (далее, просто сертификат) — это конгломерат из открытого ключа пользователя, пользовательской информации, имени сертификата, называемого Distungiushed Name (DN) и цифровой подписи удостоверяющего центра, которая скрепляет все эти данные друг с другом. То есть появляется возможность связать открытый ключ и DN пользователя, что может служить искомым ингридиентом процесса аутентификации, если в качестве идентификатора пользователя используется Distinguished Name его сертификата. Кстати говоря, у сертификата есть срок действия, который ограничивает срок соответствия, создаваемого удостоверяющим центром.
Естественно, проблема просто переносится в другое место — вместо поддержания большого списка соответствия мы теперь должны держать существенно меньший список открытых ключей удостоверяющих центров. При этом ключу удостоверяющего центра оказывается достаточно большое доверие: удостоверяющий центр подтверждает связь тысяч пользовательких имен с соответствующими открытыми ключами.
Зачем нужна аутентификация? Одного шифрования недостаточно?
Ну, во-первых, аутентификация ценна сама по себе: компьютерным системам нужно аутентифицировать своих пользователей, чтобы потом решать вопрос об авторизации их доступа к различным ресурсам.
Но если вы берете открытый ключ какого-то пользователя и хотите отправить ему зашифрованное сообщение, то вам скорее всего захочется удостовериться, что вы шифруете сообщение правильным открытым ключом, особенно если вы берете этот ключ из общедоступных источников. Ведь атакующий может поместить свой открытый ключ, но при этом указать, что ключ принадлежит вашему адресату. И если вы не аутентифицируете открытый ключ, то атакующий, перехватив ваше зашифрованное сообщение, сможет его без проблем расшифровать.
То есть введение удостоверяющего центра позволяет нам аутентфифцировать обеъкт, который владеет данным сертификатом. Естественно, перед этим мы должны довериться открытому ключу удостоверяющего центра. Это подразумевает две вещи:
- доверие удостоверяющему центру вообще, то есть доверие его репутации,
- уверенность в том, что тот открытый ключ, который к вам попал, действительно является открытым ключом данного удостоверяющего центра.
- звонить в удостоверяющий центр и сверять содержимое открытого ключа по телефону,
- приезжать в сам удостоверяющий центр и забирать открытый ключ на каком-то носителе,
- доверяться тем открытым ключам удостоверяющих центров, которые уже присутствуют в составе какого-то программного пакета
- и множество других способов, которые еще неудобнее уже названных;))
Proxy-сертификаты
Отлично: теперь у нас есть доверенные удостоверяющие центры, их открытые ключи, сертификаты пользователей и их закрытые ключи. Мы можем шифровать сообщения и может создавать цифровые подписи, отказаться от факта производства которых достаточно сложно.
Что же еще? В многокомпонентных системах очень удобно то, что называется Single Sign-On — возможность аутентифицироваться вручную только один раз, а все остальные операции аутентификации будут проводиться автоматически. Обычно это актуально в системах, которые первоначально вас аутентифицируют, а потом система начинает выполнять действия от вашего лица, например, получать данные, запускать задачи, публиковать их результаты и т.д. Это называется делегированием.
Делегирование, основанное на proxy-сертификатах, функционирует следующим образом: после взаимной аутентификации пользователя и сервиса, который в дальнейшем будет работать от имени пользователя, сервис создает новую ключевую пару и отправляет открытый ключ на подпись пользователю. Пользователь подписывает этот открытый ключ так же, как это делает удостоверяющий центр, но при это используется закрытый ключ пользователя. Появившийся в результате сертификат и называется proxy-сертификатом.
После этого сервис, который выступает от имени пользователя, может аутентифицироваться, используя свой (только что созданный) закрытый ключ и сертификат, подписанный пользователем. Процесс аутентификации проходит примерно так.
- Проверяется подпись, созданная сервисом. При этом используется открытый ключ, который был передан вместе с подписью.
- Аутентифицируется открытый ключ, которым была проверена подпись. Сначала проверяется подпись на proxy-сертификате, которая была создана с помощью закрытого ключа пользователя. Это делается с помощью открытого ключа пользователя.
- Таким же образом аутентифицируется открытый ключ самого пользователя, но здесь уже используются данные об удостоверяющем центре.
С помощью такого же механизма, сервис, которому первоначально был выдан proxy-сертификат, может подписать еще один proxy-сертификат, делегировав полномочия пользователя пользователя по цепочке другому сервису. Именно так и реализуется Single Sign-On.
- X.509 Style Guide , написанный Питером Гутманном. Там много технических деталей, но некоторым почитать вполне стоит.
Данный документ дает краткое описание стандарта X.509 различных версий. В первую очередь, внимание уделяется стандартным полям сертификата X.509 и различным дополнениям (extensions), применение которых позволяет использовать сертификаты в самых различных областях.
Сертификат X.509 версии 1 и 2
Версия 1 стандарта X.509 была издана в 1988 году. Версия 2 стандарта X.509 была издана в 1993 году и содержала минимальные дополнения к версии 1. Приведенный ниже рисунок показывают формат сертификатов версии 1 и 2.
| Version | Версия сертификата | 1, 2, 3 |
| Certificate Serial Number | Серийный номер сертификата | |
| Идентификатор алгоритма ЭЦП | ГОСТ Р 34.10-94 | |
| Issuer X.500 Name | Имя Издателя сертификата | |
| Validity Period | Срок действия сертификата | |
| Subject X.500 Name | Имя Владельца сертификата | |
| Subject Public Key Info | Открытый ключ Владельца | длина ключа: 1024 значение: AF:ED:80:43..... |
| Issuer Unique ID version 2 | ||
| Subject Unique ID version 2 | ||
| CA Signature ЭЦП Центра Сертификации |
||
Версия
Данное поле описывает версию сертификата. При использовании дополнений версия должна быть установлена как X.509 version 3 (значение равно 2). Если дополнения не используются, версия должна быть 1 (значение должно быть не установлено).
Идентификатор алгоритма ЭЦП
Поле содержит идентификатор криптографического алгоритма, используемого ЦС для выработки ЭЦП сертификата.
Серийный номер сертификата
Серийный номер является целым числом, устанавливаем ЦС для каждого сертификата. Значение должно быть уникальным для каждого сертификата, выпущенного данным ЦС. Имя Издателя и серийный номер сертификата совместно являются уникальным идентификатором сертификата.
Имя Издателя сертификата
Поле Издатель идентифицирует объект (субъект), который сформировал ЭЦП и издал сертификат. Значение в поле Издатель должно содержать ненулевое значение DN (distinguished name). Поле Издатель определено в рекомендациях X.501 как тип Name. Значение поля состоит из набора иерархических атрибутов (AttributeType), таких как код страны и соответствующего ему значения (AttributeValue, например, UA). Тип компонентов AttributeValue, входящих в имя, определяется типом атрибута AttributeType и в основном используется DirectoryString.
Срок действия сертификата
Данное поле определяет срок действия (в виде временного интервала) в течение которого ЦС управляет сертификатом (отслеживает состояние). Поле представляет последовательность двух дат: дата начала действия сертификата (notBefore) и дата окончания срока действия сертификата (notAfter). Оба этих значения могут быть закодированы либо как UTCTime, либо как GeneralizedTime.
Имя Владельца сертификата
Поле Владелец идентифицирует объект (субъект), являющийся обладателем секретного ключа, соответствующего открытому ключу в сертификате.
Открытый ключ Владельца
Данное поле используется для хранения открытого ключа и идентификации алгоритма, соответствующего открытому ключу. Поле parameters идентификатора алгоритма содержит идентификаторы соответствующих секретных ключей в виде последовательности:
SEQUENCE { signKeyIdentifier IA5String, encryptKeyIdentifier IA5String OPTIONAL }
Уникальный идентификатор Издателя и Владельца
Данное поле может использоваться только в сертификатах версии 2 или 3. Поле было предусмотрено в версии 2 сертификатов X.509 для целей обеспечения использования одинакового имени Владельца или Издателя в разных сертификатах. С введением дополнений в версии 3 такая необходимость отпала.
Сертификат X.509 версии 3
Данный раздел описывает версию 3 сертификата X.509. Версия 3 описала механизм дополнений, дополнительной информации, которая может быть помещена в сертификат. X.509 и рекомендации RFC 2459 описывают набор стандартных дополнений, но вместе с тем не ограничивают возможности использования любых других дополнений путем регистрации идентификатора (ISO или IANA).
Каждое дополнение состоит из трех полей:
| type | critical | value |
Таким образом, дополнение представляет собой структуру, содержащую:
- идентификатор дополнения
- признак "критичное/не критичное дополнение
- собственно значение дополнения, представленное в бинарном виде (OCTET STRING)
В свою очередь само дополнение может являться какой угодно сложной структурой (от простого текстового значения до сложной структуры), формат и интерпретация которого определяется идентификатором дополнения.
Рекомендации определяют основной целью критичных дополнений - предохранить сертификат, изданный ЦС, от возможности использования его в приложениях, которые не могут обработать такие дополнения. Таком образом, правила обработки дополнений, изложенные в рекомендация, требуют от прикладного ПО отвергнуть сертификат, если дополнение отмечено критичным и прикладное ПО не может его интерпретировать. В свою очередь, требование отвергнуть дополнение прикладным ПО, отмеченное как критичное, при невозможности его интерпретации, требует от прикладного ПО детального разбора дополнений сертификатов и затрудняет процесс модификации как прикладного ПО, так и ПО, обеспечивающего реализацию ИОК.
Приведенный ниже рисунок дает представление о формате сертификата версии 3.
| Version | Версия сертификата | 3 | ||
| Certificate Serial Number | Серийный номер сертификата | 40:00:00:00:00:00:00:ab:38:1e:8b:e9:00:31:0c:60 | ||
| Signature Algorithm Identifier | Идентификатор алгоритма ЭЦП | ГОСТ Р 34.10-94 | ||
| Issuer X.500 Name | Имя Издателя сертификата | C=UA, ST=Kyiv,O=PKI, CN=Certification Authority | ||
| Validity Period | Срок действия сертификата | Действителен с: Ноя 2
06:59:00 1999 GMT Действителен по: Ноя 6 06:59:00 2004 GMT |
||
| Subject X.500 Name | Имя Владельца сертификата | C=UA, ST=Kyiv, O=PKI, CN=Petrenko | ||
| Subject Public Key Info | Открытый ключ Владельца | тип ключа: Открытый
ключ ГОСТ длина ключа: 1024 значение: AF:ED:80:43..... |
||
| Issuer Unique ID version 2 | Уникальный идентификатор Издателя | |||
| Subject Unique ID version 2 | Уникальный идентификатор Владельца | |||
|
||||
| CA Signature ЭЦП Центра Сертификации |
||||
Дополнения X.509 версии 3
К стандартным дополнениям
сертификатов версии 3, относятся
дополнения определенные рекомендациями
Х.509 версии 3 ITU-T и дополнения,
определенные рекомендациями IETF RFC 2459
Базовый идентификатор дополнений,
определенный рекомендациями Х.509: id-ce
OBJECT IDENTIFIER::= {joint-iso-ccitt(2) ds(5) 29},
где id-ce обозначает: Object id
entifier assignments
for ISO c
ertificate e
xtensions.
Стандартные дополнения можно разделить на две категории: ограничивающие дополнения и информационные дополнения. Первые ограничивают область применения ключа, определенного сертификатом, или сам сертификат. Вторые содержат дополнительную информацию, которая может быть использована в прикладном ПО пользователем сертификата.
К ограничивающим дополнениям относятся:
- базовые ограничения (basicConstraints);
- область применения ключа (keyUsage);
- расширенная область применения ключа (extendedKeyUsage);
- регламенты сертификата (модифицируемые ограничениями регламентов и соответствием регламентов) (certificatesPolicies);
- ограничения имен (nameConstraints).
К информационным дополнениям относятся:
- идентификаторы ключей (subjectKeyIdentifier, authorityKeyIdentifier);
- альтернативные имена (subjectAltName, issuerAltName);
- точка распространения СОС (cRLDistributionPoint, issuingDistributionPoint);
- способ доступа к информации ЦС (authorityAccessInfo).
Идентификатор ключа Издателя
Дополнение Идентификатор ключа Издателя (authorityKeyIdentifier) используется для идентификации открытого ключа, соответствующего секретному ключу ЭЦП, использованному Центром Сертификации при подписи издаваемого сертификата (или СОС). Данное дополнение может быть использовано в случае, когда Издатель сертификата (ЦС) имеет несколько различных секретных ключей ЭЦП (например при плановой их смене), а так же для однозначного построения цепочек сертификатов. Функция построения цепочки сертификатов использует значение данного дополнения для однозначного определения сертификата Издателя.
Идентификатор ключа Владельца
Данное дополнение используется для
идентификации различных сертификатов,
содержащих открытый ключ. Для упрощения
процедуры построения цепочки, данное
дополнение должно устанавливаться во
всех сертификатах ЦС, которые включают
дополнение basicConstraints с установленным
значением cA TRUE. Во всех издаваемых ЦС
сертификатах значение keyIdentifier в
дополнении authorityKeyIdentifier должно быть
идентично значению subjectKeyIdentifier сертификата
ЦС.
Для сертификатов, значение subjectKeyIdentifier должно
вырабатываться из открытого ключа или с
использованием метода генерации
уникальных значений. Рекомендациями RFC
2459 предлагается два метода генерации
идентификатора на основе значения
открытого ключа:
(1) Значение keyIdentifier определяется как 160 бит хэш-функции, вычисляемой по алгоритму SHA-1 из значения BIT STRING subjectPublicKey (исключая тэг, длину и неиспользованные биты).
(2) Значение keyIdentifier определяется как 4-x битовое поле со значением 0100 и последующим за ним 60 битами наименьшей значимой части хэш-функции, вычисляемой по алгоритму SHA-1 из значения BIT STRING subjectPublicKey.
Для идентификации без использования
открытого ключа, можно также
использовать монотонно возрастающую
последовательность целых чисел.
Для сертификатов конечного
пользователя, данное дополнение
используется для идентификации
приложением различных сертификатов
содержащих определенный открытый ключ.
Если конечный пользователь обладает
несколькими сертификатами, особенно от
разных ЦС, данное дополнение позволяет
быстро определить требуемый сертификат.
Для этих целей данное дополнение должно
добавлять во все сертификаты конечных
пользователей.
Значение данного дополнения для
сертификатов конечных пользователей
должно формироваться из значения
открытого ключа способом описанным выше.
Данное дополнение служит для определения
взаимосвязей между различными
объектами на всем сроке существования
открытого ключа (запрос, сертификат,
сообщение о компрометации, СОС).
Область применения ключа
Данное дополнение определяет область применения секретного ключа, соответствующего открытому, содержащемуся в сертификате.
Таблица. Области применения ключа
| Флаг | Применение ключа |
| digitalSignature | Ключ может быть использован для целей обеспечения целостности и авторства информации. Формирование и проверка ЭЦП электронных документов и информации, установление идентичности в процессе аутентификации и т.д. |
| nonRepudiation | не используется |
| keyEncipherment | не используется |
| dataEncipherment | Ключ может быть использован для целей обеспечения конфиденциальности и целостности информации. Шифрование и расшифрование данных и контроль целостности с использованием имитозащиты. |
| keyAgreement | не используется |
| KeyCertSign | Ключ может быть использован для целей формирования ЭЦП сертификатов. Может использоваться Центром Сертификации и Регистрации. |
| CRLSign | Ключ может быть использован для целей формирования ЭЦП СОС. Может использоваться Центром Сертификации. |
| EncipherOnly | не используется |
| DecipherOnly | не используется |
Расширенная область применения ключа
Данное дополнение (Extended keyUsage)
предназначено для задания
дополнительных областей применения
ключа по требованиям прикладного ПО.
Значение Область применения ключа (KeyPurposeId)
данного дополнения может быть
определена любой организацией в
зависимости от конкретных целей.
Идентификатор объекта, для
идентификации области применения
должен назначаться в соответствии с IANA
или ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1.
Срок действия секретного ключа
Данное дополнение позволяет Издателю сертификата задать различные сроки действия секретного и сертификата. Дополнение содержит два опциональных компонента: notBefore и notAfter. Секретный ключ, соответствующий открытому в сертификате, не должен быть использован до или после времен, указанных соответствующими компонентами. ЦС не должен формировать сертификат, в котором не указан не один из компонентов.
Регламенты использования сертификата
Данное дополнение представляет собой
последовательность, состоящую из одного
или нескольких информаторов
регламента (PolicyInformation), каждый из
которых содержит идентификатор
объекта (OID) и опциональный квалификатор.
Данный информатор регламента отображает
регламент, с учетом которого сертификат
был издан и цели, для которых сертификат
может быть использован. Опциональный квалификатор,
который может присутствовать, не
предусмотрен для целей изменения
регламента, определенного информатором.
Приложения с определенными требованиями функционирования, должны содержать внутренний список регламентов , удовлетворяющих данным требованиям, для целей сравнения идентификаторов объектов в сертификате с имеющимся внутренним списком приложения. Если данное дополнение критичное, ПО производящее обработку должно обладать возможностью интерпретации данного дополнения (включая опциональный квалификатор). В противном случае сертификат должен быть отвергнут.
Регламенты использования сертификата аналогичны делению сертификатов на различные типы и устанавливаются в соответствующем стандартном дополнении всех сертификатов конечных пользователей.
Таблица. Информация о Регламенте сертификата
| Регламент и номер ссылки MDPREI CertPolicy n | Информация о Регламенте сертификата |
| Registration (n = 1) | Данный сертификат и соответствующий ему секретный ключ предназначен для целей, предусмотренных процессом регистрации пользователя в системе, и не могут быть использованы для обеспечения авторства, целостности и конфиденциальности любой другой передаваемой или хранимой информации. |
| Class1 (n = 2) | Центр Сертификации не гарантирует принадлежность открытого ключа и дополнений Владельцу сертификата. Использование данного сертификата в приложениях, требующих идентификации Владельца, может привести к фальсификации конфиденциальной информации. |
| Class2 (n = 3) | |
| Class3 (n = 4) | Данный сертификат и соответствующий ему секретный ключ предназначен для обеспечения авторства, целостности и конфиденциальности любой передаваемой или хранимой информации, не составляющей государственную тайну. |
Соответствие регламентов
Данное дополнение предназначено для
использования в сертификатах ЦС. Оно
содержит список парных Идентификаторов
Объектов (OID). Каждая пара в свою
очередь включает Регламент Зоны
Издателя (issuerDomainPolicy) и Регламент
Зоны Владельца (subjectDomainPolicy). Такая
парность означает, что ЦС, выступающий в
роли Издателя (issuing CA), принимает Регламент
Зоны Издателя эквивалентным Регламенту
Зоны Владельца для подчиненного ЦС (subject
CA).
Пользователи, относящиеся к Издающему
ЦС (issuing CA) могут принимать Регламент
Зоны Издателя(issuerDomainPolicy) для
соответствующих приложений. Дополнение Соответствие
Регламентов ставит в известность
пользователей Издающего ЦС о том наборе Регламентов,
subject CA) которые сравнимы с
регламентами, соответствующими их
требованиями.
Альтернативное имя Владельца
Дополнение Альтернативное Имя Владельца может использоваться для двух целей. Во-первых, оно позволяет расширить границы идентификации Владельца сертификата. Для этого используются заранее определенные идентификаторы, которые включают адрес электронной почты Internet, имя в DNS, IP адрес и URI. Во-вторых, оно предоставляет набор дополнительной справочной информации о Владельце сертификата. Для этого используется представление имени в различных видах и множественное представление имен. При необходимости введения такой дополнительной идентификации в сертификат должно использоваться дополнение Альтернативное Имя Владельца или Альтернативное Имя Издателя
В связи с тем, что альтернативное имя
может быть использовано для целей
определения соответствия Владельца и
открытого ключа, все части
идентифицирующие его и входящие в
альтернативное имя, должны быть
проверены ЦС. Уровень проверки
дополнительной информации определяется
Регламентом ЦС.
Альтернативное Имя Владельца может
быть ограничено тем же способом, что и
поле Владелец в сертификате,
используя дополнение nameConstraintsExtension.
TYPE-IDENTIFIER::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } WITH SYNTAX {&Type IDENTIFIED BY &id} Таблица. Поля дополнения Альтернативное Имя
| Наименование | Тип | Назначение | Идентификатор |
| rfc822Name | IA5String | Адрес электронной почты rfc 822 | CHOICE |
| dNSName | IA5String | Имя DNS | CHOICE |
| directoryName | IA5String | X.500 DN (имя | CHOICE |
| uniformResourceIdentifier | IA5String | адрес URI | CHOICE |
| iPAddress | OCTET STRING | Адрес IP | CHOICE |
| registeredID | OBJECT IDENTIFIER | Идентификатор ASN.1 объекта | CHOICE |
| organizationName | DirectoryString | Наименование организации | id-at 10 |
| registredAddress | DirectoryString | Зарегистрированный (юридический адрес) организации | id-at 26 |
| surname | DirectoryString | Фамилия, имя, отчество | id-at 4 |
| businessCategory | DirectoryString | Должность | Должность |
| physicalDelivery | DirectoryString | Почтовый адрес | id-at 19 |
| telephoneNumber | PrintableString | Номер телефона | id-at 20 |
| description | DirectoryString | Дополнительное описание | id-at 13 |
| accountNumber | DirectoryString | Номер банковского расчетного счета | OBJ_mdprei_extensions,10 |
| bankID | DirectoryString | Банковский идентификационный код | OBJ_mdprei_extensions,11 |
Поля с идентификаторами id-at, определены в рекомендациях Х.520.
Альтернативное имя Издателя
Так же как и дополнение Альтернативное Имя Владельца, дополнение Альтернативное имя Издателя (issuerAltName) служит целям дополнительной ассоциации Издателя сертификата. Правила использования данного дополнения аналогичны использованию дополнения Альтернативное Имя Владельца.
Атрибуты Справочника Владельца сертификата
Дополнение предусмотрено для хранения дополнительной информации, связанной с атрибутами директории X.500. Дополнение Атрибуты Справочника Владельца сертификата не рекомендуется использовать рекомендациями RFC 2459 , но он может быть использован в частных реализациях.
Основные ограничения
Дополнение Базовые ограничения идентифицирует,
является ли Владелец сертификата
Центром Сертификации, и какова длина
цепочки сертификатов для этого ЦС.
Поле pathLenConstraint имеет смысл только
при условии, если значение cA установлено
в TRUE. В этом случае оно обозначает
максимальное количество сертификатов
ЦС, которые следуют за данным
сертификатом в цепочке. Значение нуль
означает, что только сертификаты
конечного пользователя могут следовать
в цепочке за данным сертификатом. При
использовании, значение pathLenConstraint
больше или равно нулю. Если значение не
установлено, это означает, что лимит на
длину цепочки не определен.
Ограничения имени
Дополнение Ограничение имени,
должно использоваться только в
сертификатах ЦС. Оно указывает
пространство имен, внутри которого
должны быть расположены все имена
Владельцев издаваемых сертификатов.
Ограничения могут быть применимы как
имени Владельца (Subject DN), так и к
альтернативному имени.
Ограничения определены в терминах
допускаемого (permittedSubtrees) или
исключаемого (excludedSubtrees) поддерева
имен. Любое имя совпадающее с
ограничением в исключающем поддереве
является некорректным, в независимости
от возможного его присутствия в
допускаемом поддереве.
При реализации данного дополнения RFC 2459
рекомендуется:
- не использовать поля minimum и maximum ни в какой из форм имен, так что minimum всегда нуль, а maximum всегда отсутствует;
- использовать только поля permittedSubtrees для задания разрешенного диапазона имен и не использовать excludedSubtrees, что согласуется с организационной или территориальной схемой иерархии.
Ограничение регламента
Данное дополнение может быть использовано в сертификатах, издаваемых для ЦС. Дополнение Ограничение регламента накладывает ограничения на проверяемую цепочку в двух направлениях. Оно может использоваться для запрещения проверки соответствия регламентов (policy mapping) или требовать, чтобы каждый сертификат в в цепочке содержал приемлемый идентификатор регламента (policy identifier).
Точка распространения СОС
Точка распространения СОС является дополнением, которое определяет механизм и расположение СОС определенного типа в сети, и определяет зону действия СОС как:
- только для конечных пользователей,
- только для ЦС,
- или ограничивает коды мотивации.
Коды мотивировки, ассоциированные с точкой распространения, должны специфицироваться в поле onlySomeReasons. Если поле onlySomeReasons отсутствует, точка распространения должна содержать отзываемые сертификаты для всех кодов. ЦС может использовать Точку распространения СОС как основу для управления потоками данных при компрометации. В этом случае, отзывы сертификатов с кодами keyCompromise (1) и cACompromise (2) располагаются в одной точке распространения, а все остальные в другой.
Способ доступа к информации ЦС
Данное дополнение указывает на способы доступа к информации и сервисам ЦС, издавшим сертификат, в котором это дополнение установлено. Информация и сервис могут включать процедуры on-line проверки и получения Регламента (Регламентов) ЦС. Способ получения СОС не специфицируется данным дополнением, для этого используется дополнение cRLDistributionPoints.
Достаточно часто администраторы занимаются выпуском сертификатов с использованием нескольких имён. Например, когда нужно привязать один сертификат к нескольким именам: mail.company.com и owa.compny.com. Однако поле Subject может содержать только одно имя. Для разрешения этой проблемы используется расширение Subject Alternative Name (SAN ). В этом расширении вы можете использовать сколько угодно дополнительных имён для сертификата.
Но как правильно же оформить несколько имён в сертификате на примере mail.company.com и owa.company.com? Здесь варианта всего 2:
- Использовать поле Subject и расширение SAN
Данный способ используется чаще для внешних сертификатов. Поле Subject заполняется следующим образом (красным выделены обязательные компоненты):
CN = mail.company.com
OU = <название подразделения>
OU = <ещё какое-то название подразделения>
O = <название организации>
L = <местоположение компании>
C = <код страны, где расположена компания>
Т.е. включается основное имя сертификата (по правде говоря, при использовании SAN, понятие основного имени отсутствует, т.к. все имена считаются равноценными. Здесь следует указывать имя, которое будет использоваться чаще всего приложениями, неподдерживающими расширение SAN) и опционально можно задать дополнительные DN суффиксы, отражающие принадлежность сертификата. И расширение SAN заполняется следующим образом:
DNS Name=mail.company.com
DNS Name=owa.company.com
Как видите, имя из Subject продублировано в SAN. Дело в том, что если в сертификате есть расширение SAN и приложение умеет его обрабатывать, приложение как правило настраивается только на проверку расширения SAN и в Subject они не заглядывают. Но это не всегда так. Иногда приложение смотрит и в Subject и в SAN. В таком случае имена дублировать не обязательно. Но в целях обеспечения совместимости следует ВСЕГДА дублировать имя из Subject в расширении SAN.
- Использовать только расширение SAN
Этот способ редко применяется во внешних сертификатах, а только внутренних. В этом случае поле Subject не заполняется совсем и оставляется пустым. А расширение SAN будет включать все необходимые имена:
DNS Name=mail.company.com
DNS Name=owa.company.com
Такая форма заполнения поддерживается в Internet PKI и описана в RFC 5280 . Согласно этому RFC, если поле Subject не определено (пусто), имя для сертификата выбирается из расширения SAN, а само расширение помечается как критичное (см. RFC 5280 §4.2.1.6). Вот примерные пруфпики, как это выглядит в жизни:
на вкладке General имя формируется либо из первого имени в расширении SAN или из имени используемого конкретным приложением (например, при просмотре из браузера) и котрое перечислено в расширении SAN.
Здесь продемонстрировано пустое поле Subject.
И перечисление необходимых имён в расширении SAN. Критичность расширения определяется по наличию жёлтого треугольничка и восклицательного знака.
На заметку : что такое критичное расширение (critical extension)? Это просто расширение, которое приложение должно проверить в обязательном порядке. Если приложение видит такое расширение, приложение должно уметь его обработать и понять значение в этом расширении. Если приложение не знает, что делать с этим расширением или приложение не может разобрать значение этого расширения, приложение обязано отклонить данный сертификат. Более подробно о порядке поведения приложения.
Примечание: хоть и заявляется, что приложение должно отклонить сертификат, если значение расширения непонятно, это не в полной мере относится к расширению SAN. Приложение не обязано поддерживать все формы SAN, а может поддерживать только некоторые формы, например, только DNS Name. Но если поддерживаемая форма не может быть распознана, сертификат должен быть отклонён.
Поскольку расширение SAN является единственным средством идентификации имени сертификата, вполне логично ожидать, что это расширение будет помечено как критичное и обязательное для обработки приложением.
Какой способ из двух выбрать? А какой считаете более приемлемым. Если это сертификат внешнего веб-сервера, целесообразно использовать первый вариант, поскольку при помощи DN суффиксов можно конкретизировать принадлежность сертификата к вашей компании. А так же если предполагается доступ из приложений неподдерживающих расширение SAN. Это не обязательно компьютерные приложения, это могут быть приложения мобильных устройств. В целях избежания чрезмерного пиара VeriSign"a в моём бложике, представляю образцово-показательный сертификат выполненный первым способом на сайте Thawte: https://www.thawte.com/
Для использования внутри организации можно использовать и второй вариант, с пустым Subject. Например, для логонных сертификатов смарт-карт. Контроллеры домена вообще не смотрят на Subject логонного сертификата, а смотрят только в SAN на предмет наличия UPN в расширении.
