Электронный сертификат X.509 обзор RFC технические спецификации стандарты ССЛ сертификат SSL Украина купить сертификат

Электронный сертификат X.509 обзор RFC технические спецификации стандарты  ССЛ сертификат SSL Украина купить сертификат Сертификаты

Образовательная сеть доверия на основе сертификатов стандарта x.509

Этот проект сети взаимного доверия основан на PKIX и предназначен для авторизованной рассылки учебных заданий, получения отчётов об их выполнении и консультаций, а также для получения сертификатов на коммерческих УЦ[8].

Ec permis

Проект EC PERMIS разработал роли, основанные на инфраструктуре управления доступом. Для хранения ролей пользователей используются сертификаты X.509. Сертификат X.509 хранит политику авторизации в формате XML по DtD (англ. Data transfer Device), с помощью которой производится управление доступом.

В проекте используется распределитель привилегий, который является инструментом, создающим и подписывающим сертификаты и сохраняющий их в каталог LDAP для последующего их использования функцией контроля доступом[9].

Безопасность

Опубликована информация о коллизиях в алгоритме хеширования MD5 в 2004 году и об атаках на этот алгоритм, которые совершили Арьен Ленстра, Ван Сяоюнь и Бенн де Уэгер. Они подделали два сертификата с одинаковыми подписями.

Использование криптографических хеш-функций SHA-1 только частично решает проблему, так как согласно теории подобная атака возможна, даже если сложность поиска коллизий на SHA-1 намного больше, чем MD5, согласно RFC 3279. Необходимо помнить, что взаимодействие ведётся с людьми и УЦ.

Надёжность, безопасность и прочие достоинства использования сертификатов X.509 определяются самым слабым звеном во всех системах безопасности: конкретными людьми или УЦ. Известные проблемы стандарта X.509: невозможность оперативного исключения корневого сертификата, или трудоёмкая процедура получения сертификата в целом.

Иерархическая pki

Согласно RFC 4387, суть PKI следующая: в браузере хранятся не сертификаты сайтов, а сертификаты УЦ. Это означает, что когда ваш браузер получает сертификат сайта при установке соединения, он видит помимо адреса сайта ещё и «адрес» УЦ, а также цифровую подпись, которую сгенерировал УЦ с использованием своего секретного ключа.

Согласно RFC 5280, цепь сертификатов представляет собой список сертификатов (начиная с лица, удостоверенного в качестве сервера), включающий один или несколько УЦ (последний подписывается самим собой), обладает следующими свойствами:

  1. Подпись каждого сертификата (за исключением последнего) является удостоверяющим центром-преемником.
  2. Все сертификаты, за исключением последнего, подписываются с помощью закрытого ключа следующего УЦ.
  3. Последний сертификат в цепи является сертификатом единственного пункта доверия, являющегося корневым УЦ.

Иерархические PKI способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей.

История

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

Одним из способов её решения является механизм сертификации участников информационного обмена. С целью обеспечения функциональной совместимости различных программно-аппаратных продуктов (средств криптографической защиты информации), использующихся в таких прикладных сервисах (WWW, электронная почта, системы аутентификации пользователей и др.) был создан стандарт, описывающий формат сертификатов, который был впервые опубликован ITU-T в 1988 году в качестве части рекомендаций X.

500 (RFC 5280)[2]. Это был X.509 v1. В 1993 году в описание стандарта сертификатов добавили 2 поля, что привело к появлению X.509 v2, а ещё несколько позже появилась третья версия стандарта — X.509 v3

[⇨]

Вопросами реализации стандарта в сети Интернет занимается рабочая группа IETF, сформированная в 1995 году и более известная как Public-Key Infrastructure (X.509) working group (PKIX). Результатами её работы, в частности, стали рекомендации RFC 3280 и 5280[3].

X.509 стал основой для построения иерархической системы удостоверяющих центров

[⇨]

, несмотря на появление в 1991 году технологии

. Стандарт поддерживается в таких протоколах и механизмах как

Модель безопасности для сред мобильный агент, использующих прокси-сертификаты x.509

Технология Мобильный Агент (далее — «МА») представляет собой привлекательную альтернативу для клиент-серверной архитектуры при использовании её для нескольких сетей и приложений в режиме реального времени. Предложена модель безопасности для МА на основе инфраструктуры безопасности для вычислительных сетей, и, в частности, на основе прокси-сертификатов X.509.

Прокси-сертификаты служат в качестве учетных данных для сетевых приложений, и их основной целью является временное делегирование полномочий. Используя сходство между грид-приложениями и приложениями МА, можно использовать прокси-сертификаты в качестве учетных данных для МА.

Новое расширение для прокси-сертификатов предлагается для того, чтобы сделать их подходящими для их применения в системах МА и в других механизмах в целях ограничения прав агентов и в целях безопасного делегирования полномочий во время прибытия новых агентов[10].

Общеупотребительные расширения файлов сертификатов

  • .CER — сертификат, или набор сертификатов, закодированных по стандарту CER.
  • .DER — сертификат, закодированный по стандарту DER.
  • .PEM — DER-сертификат, закодированный в Base64 и помещенный между «—— BEGIN CERTIFICATE ——» и «—— END CERTIFICATE ——».
  • .P7B, .P7C — PKCS #7 содержит несколько сертификатов или CRL.
  • .P12 — PKCS #12 содержит блок, хранящий одновременно и закрытый ключ, и сертификат (в зашифрованном виде).
  • .PFX — PFX, предшественник PKCS #12, также содержит блок закрытого ключа и сертификат.

Особенности

Для выпуска сертификатов существует четко определённая иерархическая система удостоверяющих центров (далее — УЦ)

[⇨]

, согласно

. В этом его отличие от моделей, основанных на принципе сети доверия (

Web of trust

), подобной криптографической технологии

, где любой (не только УЦ) может выпускать, подписывать и проверять на соответствие сертификат. Согласно

, X.509 v3 обладает гибкостью для поддержки таких топологий как

bridges

) и

meshes

), а также может быть использован в

сетях.

Добавлены расширения и особенность критичности для X.509 в 1995 году[6].

Существуют ограничения стандарта X.509 при использовании его для шифрования сообщений электронной почты и совместной работы приложений. X.509 предлагает неполную совместимость работы приложениями. А значит, могут возникнуть проблемы при работе с API[7].

Примечания

  1. «Recommendation ITU-T X.509», на веб-сайте ITU, 2021  (Проверено 10 февраля 2021).
  2. « L’annuaire — Cadre d’authentification » на веб-сайте ITU, 2008  (Проверено 11 февраля 2021).
  3. Public-Key Infrastructure (X.509) (pkix) (неопр.). IETF Datatracker. Дата обращения: 11 марта 2021.
  4. 12Turcotte Y.Syntax testing of the entrust public key infrastructure for security vulnerabilities in the X.509 certificate (англ.) // Royal Military College of Canada (Canada) : диссертация. — 2005.
  5. Tremblett P.X.509 certificates (англ.) // Miller Freeman Inc. — 1999. — Vol. 24, no. 7. — P. 42—48. — ISSN1044-789X.
  6. X.509 security update (англ.) // CMP Media LLC. — 1995. — Vol. 24, no. 10. — P. 14. — ISSN0363-6399.
  7. Lewis J.X.509 is a start, but it’s no panacea (англ.) // Ziff Davis Media Inc. : статья в журнале. — 1997. — Vol. 14, no. 37. — P. 109. — ISSN0740-1604.
  8. Хорев Павел Борисович.Образовательная сеть доверия на основе сертификатов стандарта X.509 (рус.) // Издательский дом МЭИ (Москва) : конференция. — 2021. — 12—13 апреля.
  9. Chadwick D.W., Otenko A.The PERMIS X.509 role based privilege management infrastructure (англ.) // Elsevier Science Publishing Company, Inc. — 2003. — Vol. 19, no. 2. — P. 277—289. — ISSN0167-739X.
  10. Raghunathan S.A security model for mobile agent environments using X.509 proxy certificates (англ.) // University of North Texas : диссертация. — 2003.
  11. Arjen Lenstra, Xiaoyun Wang, Benne de Weger. Colliding X.509 Certificates based on MD5-collisions, Eindhoven University of Technologies News (1 марта 2005 года).
  12. J.R. Prins (CEO Fox-IT). DigiNotar Certificate Authority breach “Operation Black Tulip” (англ.) (PDF), FOX-IT BV (5 сентября 2021).
  13. Hans Hoogstraaten (Team leader), Ronald Prins (CEO), Daniël Niggebrugge, Danny Heppener, Frank Groenewegen, Janna Wettinck, Kevin Strooy, Pascal Arends, Paul Pols. Robbert Kouprie, Steffen Moorrees, Xander van Pelt, Yun Zheng Hu. Report of the investigation into the DigiNotar Certificate Authority breach (англ.) (PDF), FOX-IT BV (13 августа 2021).
  14. Jim Fenton. Top of Mind: Reexamining Public Key Infrastructure (англ.), Cisco Blogs (14 ноября 2021 года). Архивировано 23 декабря 2021 года.
  15. Michael Gielesberger.Alternatives to X.509 (англ.) // Technical University of Munich : Internet Seminar. — 2021. — 1 февраль.

Проверка правильности установки 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.

Про сертификаты:  Перенос контейнеров закрытых ключей и сертификатов CryptoPro | Digital Cub.

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

К ограничивающим дополнениям
относятся:

  • базовые ограничения (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}

Таблица. Поля дополнения
Альтернативное Имя

НаименованиеТипНазначениеИдентификатор
rfc822NameIA5StringАдрес электронной
почты rfc 822
CHOICE [1]
dNSNameIA5StringИмя DNSCHOICE [2]
directoryNameIA5StringX.500 DN (имяCHOICE [4]
uniformResourceIdentifierIA5Stringадрес URICHOICE [6]
iPAddressOCTET STRINGАдрес IPCHOICE [7]
registeredIDOBJECT 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
bankIDDirectoryString Банковский
идентификационный код 
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. 

Ссылки

Как только страница обновилась в Википедии она обновляется в Вики 2.Обычно почти сразу, изредка в течении часа.

Структура сертификата x.509

В 4 разделе RFC 2459 описана структура сертификата X.509 v3. Обновленная структура сертификата X.509 v3 описана в документе RFC 5280 в 4 разделе. Она специализирована под интернет-приложения.

Для описания внутренней структуры сертификатов X.509 используется ASN.1. Хранятся, как правило, в виде DER или PEM-файлов. Общепринятое расширение .cer или .crt. Может быть и другое расширение

[⇨]

Тестирование синтаксиса инфраструктуры открытых ключей на уязвимости в сертификате x.509

Министерство национальной обороны Канады определило потребность в создании универсальной PKI для управления своей повседневной деятельностью и установления доверия к продуктам PKI.

За основу взяли подход PROTOS по тестированию протоколов, использовав правила кодирования BER. Были использованы модели и инструменты для тестирования реализации системы доверия PKIX на уязвимости в системе безопасности. В рамках тестирования использовался синтаксис сертификата X.

Оцените статью
Мой сертификат
Добавить комментарий