- Настройка FreeRADIUS.
- 1 Установка корневого сертификата CA напрямую.
- 4 файл /etc/raddb/eap.conf
- Установка сертификатов через MMC
- Настройка беспроводной сети на клиенте.
- Проверка правильности установки ssl сертификата онлаин. справочные материалы по установке и использованию сертификатов безопасности ssl
- Формат сертификатов открытых ключей x.509
- Хранение
Настройка FreeRADIUS.
Начнем с установки и настройки FreeRADIUS сервера.
В операционной системе Gentoo это делается довольно просто, достаточно ввести команду
=====================================================
root@s2 ~ # emerge -av freeradius
These are the packages that I would merge, in order:
Calculating dependencies …done!
[ebuild N ] net-dialup/freeradius-1.0.5-r1 -edirectory
-frascend -frnothreads -frxp -kerberos -ldap -mysql pam
-postgres -snmp ssl -udpfromto 2,240 kB
Total size of downloads: 2,240 kB
Do you want me to merge these packages? [Yes/No]
=====================================================
Если планируется хранить базу пользователей во внешних базах (например, ldap, mysql или postgre), то перед сборкой RADIUS сервера надо активировать соответствующие флаги, позволяющие собрать FreeRADIUS с поддержкой mysql/postgre и/или ldap:
=====================================================
# USE=”mysql ldap” emerge -av freeradius
=====================================================
После проверки включенности нужных флагов, достаточно нажать клавишу Y и пакет будет собран и установлен в систему:
=====================================================
<….>
— !targe sym /usr/lib/rlm_digest-1.0.5.la
— !targe sym /usr/lib/rlm_detail.so
— !targe sym /usr/lib/rlm_detail-1.0.5.la
— !targe sym /usr/lib/rlm_counter.so
— !targe sym /usr/lib/rlm_counter-1.0.5.la
— !targe sym /usr/lib/rlm_checkval.so
— !targe sym /usr/lib/rlm_checkval-1.0.5.la
— !targe sym /usr/lib/rlm_chap.so
— !targe sym /usr/lib/rlm_chap-1.0.5.la
— !targe sym /usr/lib/rlm_attr_rewrite.so
— !targe sym /usr/lib/rlm_attr_rewrite-1.0.5.la
— !targe sym /usr/lib/rlm_attr_filter.so
— !targe sym /usr/lib/rlm_attr_filter-1.0.5.la
— !targe sym /usr/lib/rlm_always.so
— !targe sym /usr/lib/rlm_always-1.0.5.la
— !targe sym /usr/lib/rlm_acct_unique.so
— !targe sym /usr/lib/rlm_acct_unique-1.0.5.la
— !targe sym /usr/lib/libradius.so
— !targe sym /usr/lib/libradius-1.0.5.la
— !targe sym /usr/lib/libeap.so
— !targe sym /usr/lib/libeap-1.0.5.la
>>> original instance of package unmerged safely.
>>>
Вышеприведенный лог сборки (его конец) показывает, что FreeRADIUS 1.0.5 успешно установлен в систему (о чем сообщает строка ” net-dialup/freeradius-1.0.5-r1 merged”). Можно приступать к его настройке.
1 Установка корневого сертификата CA напрямую.
Для начала, необходимо установить корневой сертификат CA (сертификационного центра). Просто открываем в Windows Explorer-е директорию, где у нас лежат файлы сертификатов, и два раза щелкаем на созданном ранее файле tmp_org-ca.crt
В ответ получаем окошко, где нам предлагается установить сертификат в систему. Можно сразу щелкнуть по кнопке “Установить сертификат”, а можно предварительно побегать по закладкам:
Закладка “Состав” показывает все параметры сертификата. Особенно интересны пункты “Действителен с” и “Действителен по” — сертификат будет действителен только в этом промежутке времени. Если им воспользоваться раньше или позже указанного времени, он будет отвергнутым (это касается сертификатов любых типов — как серверных, так и клиентских).
“Путь сертификации” показывает, что сертификат является корневым (самоподписанным).
После нажатия кнопки “Установить сертификат” в закладке “Общие”, мы попадем в мастер импорта сертификатов.
Операционная система сама разберется, куда помещать сертификат, поэтому можно оставить галку на “Автоматически выбрать хранилище”.
… осталось нажать кнопку “готово”.
Выскакивает последнее предупреждение об установке нового центра сертификации “tmp_org root CA”.
После нажатия на кнопку “да” в предыдущем меню, система сообщит нам, что импорт выполнен. Тем не менее, даже после нажатия на “ОК”, основное окошко с сертификатом продолжает сообщать, что сертификат неизвестен. Это всего лишь “фича” операционной системы. Достаточно закрыть то окно и открыть его заново (два раза щелкнуть на файл с сертификатом):
В этом случае нам уже сообщают, что сертификат известен и ему доверяют.
4 файл /etc/raddb/eap.conf
Переходим к настройке протокола EAP. Его настройки располагаются в отдельном файле, который, в свою очередь, подключается к основному /etc/raddb/radiusd.conf вот такой конструкцией:
#—————————————————-
$INCLUDE ${confdir}/eap.conf
#—————————————————-
Открываем /etc/raddb/eap.conf
В секции eap{ }
#—————————————————-
default_eap_type = peap # по-умолчанию, используем EAP-PEAP
#—————————————————-
Раскомментируем секцию, относящуюся к peap:
#—————————————————-
peap {
default_eap_type = mschapv2
}
#—————————————————-
Но этого недостаточно для функционирования PEAP, нам также необходимо активировать (раскомментировать) секцию, отвечающую за EAP-TLS:
#—————————————————-
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem
certificate_file = ${raddbdir}/certs/cert-srv.
В данном случае использованы цифровые сертификаты, сгенерированные автоматически, при установке пакета freeradius. Можно, конечно, создать собственные сертификаты, подписанные своим (или сторонним) сертификационным центром, но для простоты объяснения, этот этап опущен (он будет подробно расписан в следующей части статьи). Для работы RADIUS-сервера для обеспечения работы EAP-PEAP протокола, вышеприведенных настроек будет достаточно.
Установка сертификатов через MMC
Пара способов установки клиентских сертификатов уже была описана в четвертой части:
К сожалению, так можно установить только клиентские сертификаты (и корневые). И те и другие будут храниться в профиле пользователя.
Для установки сертификата компьютера, который будет храниться в системном профиле (куда ОС будет иметь доступ даже без наличия сети), необходимо воспользоваться Microsoft Managment Console (MMC).
Для этого идем в “Пуск” -> “Выполнить”.
В окне запуска программы пишем “mmc” и жмем клавишу “OK”.
В открывшемся окне консоли необходимо добавить оснастку сертификатов.
Для этого идем в меню “Консоль”. И выбираем пункт “Добавить или удалить оснастку”.
На закладке “Изолированная оснастка” жмем кнопку “добавить”.
В появившемся списке выбираем оснастку “Сертификаты” и жмем кнопку “Добавить”.
Появляется меню, в котором необходимо выбрать, какими сертификатами мы будем управлять.
Пункт “моей учетной записи пользователя” позволит добавить оснастку управления пользовательскими сертификатами. Именно ими мы и управляли в предыдущей статье с помощью интерфейса IE.
Добавляем пользовательскую оснастку.
Теперь таким же образом добавляем оснастку для управления сертификатами учетной записи компьютера:
Сертификаты компьютера невозможно добавить напрямую или через IE. Они добавляются только через MMC-консоль.
При добавлении оснастки управления сертификатами компьютера, появляется меню, где можно указать, каким именно компьютером мы хотим в данный момент управлять — выбираем “локальным компьютером” (в принципе, администратор домена может удаленно управлять оснастками и на удаленных машинах).
В результате мы добавили две оснастки — для управления сертификатами пользователя и компьютера.
Теперь подробнее рассмотрим, что эти оснастки из себя представляют.
Раскрываем дерево сертификатов текущего пользователя. Идем вниз по дереву: “Личные” -> “Сертификаты”.
Настройка беспроводной сети на клиенте.
Профиль опять-таки настраивается похожим на предыдущий случай образом. Но тут присутствуют существенные отличия.
Заходим в Zero Config Utility, жмем на “Изменить порядок предпочтения сетей”.
В закладке “Беспроводные сети” жмем кнопку “Добавить”.
В закладке “Связи” вводим имя сети (WPA-TLS), в качестве проверки подлинности опять выбираем WPA, а шифрование данных — AES.
Пока все то же самое, не так ли? А с закладки “Проверка подлинности” появляются отличия.
В качестве “Типа EAP” выставляем “Смарт карта или другой сертификат”.
Галка “Проверять подлинность как у компьютера при доступности сведений о компьютере” пока не нужна, ее необходимость будет рассмотрена позже.
Теперь жмем на кнопку “Свойства”.
В появившемся окне свойств сертификата необходимо выбрать “использовать сертификат на этом компьютере”, то есть сказать системе, что аутентификация происходит с помощью клиентского сертификата, расположенного на компьютере.
После чего активировать “проверку сертификата сервера” и в появившемся внизу списке сертификатов корневых серверов выбрать наш личный центр — tmp_org root CA.
Конечно, можно не активировать проверку сертификата сервера, но ведь мы настраиваем безопасную сеть, не так ли? И должны убедиться, что точка доступа наша, так как обращается к нашему RADIUS-серверу. При подключении к точке доступа, она (а точнее RADIUS) предъявляет свой, серверный сертификат, также подписанный корневым tmp_org root CA.
Также можно оставить включенной проверку сертификата сервера, но не выбирать в списке корневой сертификат нашего центра.
Тогда при первом подключении к точке доступа, в трее выскочит окошко, предлагающее убедиться в валидности предъявляемого радиусом сертификата. После клика на нем,
появится окно, сообщающее, что корневым сертификатом для предъявленного сервером радиуса, является “tmp_org root CA”. Если нажать ОК, то соединение продолжится.
Если же убрать галку с “проверка сертификата сервера”, то никаких проверок валидности серверного сертификата на клиенте производиться не будет. Но это небезопасно — кто угодно может поставить собственную точку доступа, настроенную аналогично нашей (то же имя сети (SSID), те же параметры шифрования и собственный центр сертификации), в результате мы подключимся к чужой сети, возможно, с самыми печальными последствиями.
Последняя закладка — “Подключение” — в свойствах беспроводной сети позволяет активировать автоматическое подключение к сети, как только она будет обнаружена клиентом.
Проверка правильности установки ssl сертификата онлаин. справочные материалы по установке и использованию сертификатов безопасности ssl
Данный документ дает краткое описание
стандарта X.509 различных версий. В первую
очередь, внимание уделяется стандартным
полям сертификата X.509 и различным
дополнениям (extensions), применение которых
позволяет использовать сертификаты в
самых различных областях.
Сертификат X.509 версии 1 и 2
Версия 1 стандарта X.509 была издана в 1988
году. Версия 2 стандарта X.509 была издана в
1993 году и содержала минимальные
дополнения к версии 1. Приведенный ниже
рисунок показывают формат сертификатов
версии 1 и 2.
Версия
Данное поле описывает версию
сертификата. При использовании
дополнений версия должна быть
установлена как 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).
Каждое дополнение состоит из трех
полей:
Таким образом, дополнение
представляет собой структуру,
содержащую:
- идентификатор дополнения
- признак “критичное/не критичное дополнение
- собственно значение дополнения,
представленное в бинарном виде (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 | Уникальный идентификатор Владельца | |
| дополнения (только версия 3) | ||
| 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 identifier assignments
for ISO certificate extensions.
Стандартные дополнения можно
разделить на две категории: ограничивающие
дополнения и информационные
дополнения. Первые ограничивают область
применения ключа, определенного
сертификатом, или сам сертификат. Вторые
содержат дополнительную информацию,
которая может быть использована в
прикладном ПО пользователем
сертификата.
К ограничивающим дополнениям
относятся:
- базовые ограничения (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.
В соответствии с рекомендациями X.681
синтаксис поля определен в следующем
виде:
TYPE-IDENTIFIER ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id} Таблица. Поля дополнения
Альтернативное Имя
| Наименование | Тип | Назначение | Идентификатор |
| rfc822Name | IA5String | Адрес электронной почты rfc 822 | CHOICE [1] |
| dNSName | IA5String | Имя DNS | CHOICE [2] |
| directoryName | IA5String | X.500 DN (имя | CHOICE [4] |
| uniformResourceIdentifier | IA5String | адрес URI | CHOICE [6] |
| iPAddress | OCTET STRING | Адрес IP | CHOICE [7] |
| registeredID | OBJECT IDENTIFIER | Идентификатор ASN.1 объекта | CHOICE [8] |
| 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) располагаются в одной точке
распространения, а все остальные в
другой.
Способ доступа к информации ЦС
Данное дополнение определено в
рекомендациях IETF RFC 2459 (в отличие от
остальных стандартных дополнений,
которые определены как в рекомендациях
X.509, так и в RFC 2459).
Данное дополнение указывает на
способы доступа к информации и сервисам
ЦС, издавшим сертификат, в котором это
дополнение установлено. Информация и
сервис могут включать процедуры on-line
проверки и получения Регламента (Регламентов)
ЦС. Способ получения СОС не
специфицируется данным дополнением, для
этого используется дополнение cRLDistributionPoints.
Формат сертификатов открытых ключей x.509
Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) [78] и документе RFC 3280 Certificate & CRL Profile [167] организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). IETF является открытым интернациональным сообществом исследователей, разработчиков сетевых протоколов, операторов и производителей, занимающихся проблемами развития сетей Интернет и обеспечением непрерывного функционирования существующей инфраструктуры.
В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения,
с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC 3820 адресован Интернет-сообществу, формат сертификата открытого ключа предоставляет гибкий механизм передачи разнообразной информации и применяется в корпоративных PKI.
Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1. Сертификат содержит элементы данных, сопровождаемые цифровой подписью издателя сертификата (см. рис. 6.
1 и табл. 6.1). В сертификате имеется десять основных полей: шесть обязательных и четыре опциональных. Большая часть информации, указываемой в сертификате, не является обязательной, а содержание обязательных полей сертификата может варьироваться. К обязательным полям относятся:
Под субъектом сертификата понимается сторона, которая контролирует секретный ключ, соответствующий данному открытому ключу. Наличие необязательных полей характерно для сертификатов версий 2 и 3, к необязательным полям сертификата относятся номер версии, два уникальных идентификатора и дополнения. Структура сертификата представлена на рис. 6.1.
ПолеVersion (см. табл. 6.1) задает синтаксис сертификата, по умолчанию предполагается первая версия сертификата. Если в поле версии указывается 2, то сертификат содержит только уникальные идентификаторы, а если 3, то в сертификат включаются и уникальные идентификаторы, и дополнения, что характерно для всех современных сертификатов. Сертификаты первой версии не содержат уникальные идентификаторы или дополнения.
Издатель сертификатов присваивает каждому выпускаемому сертификату серийный номер Certificate Serial Number, который должен быть уникален. Комбинация имени издателя и серийного номера однозначно идентифицирует каждый сертификат.
В полеSignature Аlgorithm Identifier указывается идентификатор алгоритма ЭЦП, который использовался издателем сертификата для подписи сертификата, например ГОСТ Р 34.10-94 (см. рис. 6.2).
ПолеIssuer Name содержит отличительное имя (формата X.500) третьей доверенной стороны, то есть издателя, который выпустил этот сертификат.
ПолеSubject Name содержит отличительное имя субъекта, то есть владельца секретного ключа, соответствующего открытому ключу данного сертификата. Субъектом сертификата может выступать УЦ, РЦ или конечный субъект.
Хранение
Теперь, когда у нас есть все сертификаты, необходимо их сохранить. В руководстве openssl обычно предлагается хранить сертификаты в формате pem, разбив их на открытую часть public.crt и private.key. Полученные на предыдущих этапах сертификаты являются экземплярами класса X509Certificate2, который имеет все необходимые для нас свойства и методы.
StringBuilder builder = new StringBuilder();
builder.AppendLine("-----BEGIN CERTIFICATE-----");
builder.AppendLine(Convert.ToBase64String(clientCert.RawData, Base64FormattingOptions.InsertLineBreaks));
builder.AppendLine("-----END CERTIFICATE-----");
File.WriteAllText("public.crt", builder.ToString());Также сохраним закрытый ключ:
string name = clientKey.SignatureAlgorithm.ToUpper();
StringBuilder builder = new StringBuilder();
builder.AppendLine($"-----BEGIN {name} PRIVATE KEY-----");
builder.AppendLine(Convert.ToBase64String(clientKey.ExportRSAPrivateKey(), Base64FormattingOptions.InsertLineBreaks));
builder.AppendLine($"-----END {name} PRIVATE KEY-----");
File.WriteAllText("private.key", builder.ToString());Отмечу, что метод ExportRSAPrivateKey появился только в netcore 3.0, поэтому в предыдущих версиях могут возникнуть проблемы.
Еще один способ хранения сертификатов — формат pkcs12 или pfx, позволяющий уместить в одном файле открытую и закрытую часть. Класс X509Certificate2 содержит метод Export, принимающий в качестве аргумента необходимый нам ключ X509ContentType.
Pkcs12 или X509ContentType.Pfx. Однако на этом этапе возникают трудности, поскольку загруженный обратно из файла сертификат неожиданно не содержит приватного ключа, о чем свидетельствует флаг cert.HasPrivateKey == false.
Дело в том, что класс X509Certificate2 содержит внутреннюю метку, описывающую, куда и как экспортируется закрытый ключ. Эта метка инициализируется только с помощью конструктора и не может быть изменена после. Поэтому для создания файла p12 или pfx, необходимы дополнительные усилия:
var exportCert = new X509Certificate2(clientCert.Export(X509ContentType.Cert), (string)null, X509KeyStorageFlags.Exportable | X509KeyStorageFlags.PersistKeySet).CopyWithPrivateKey(clientKey);
File.WriteAllBytes("client.pfx", exportCert.Export(X509ContentType.Pfx));
File.WriteAllBytes("client.p12", exportCert.Export(X509ContentType.Pkcs12));При желании можно использовать перегрузки метода Export с паролем.
Для работы с коллекциями сертификатов в .net core удобно использовать специализированное хранилище, реализуемого классом X509Store. Хранилище в простом случае инициализируется строковым именем:
X509Store store = new X509Store("test");
store.Open(OpenFlags.ReadWrite);
store.Add(cert);В результате для OC Linux будет создана папка “~/.dotnet/corefx/cryptography/x509stores/ test/” и файл “827…E3E.pfx”, соответсвующий цифровому отпечатку (поле Thumbprint). Попытка что-то сделать с этим сертификатом с помощью openssl не увенчается успехом, так как он ожидаемо запаролен.