X.509 своми силами в .Net Core / Хабр

Однако потом что-то пошло не так, кто-то оказался не готов, и использование ГОСТ Р 34.10-2001 продлили на 2021 год. Но вдруг все бросились переводить УЦ на ГОСТ Р 34.10-2021, а простых граждан переводить на новые сертификаты. У людей на руках стало по нескольку сертификатов. При проверки сертификатов или электронной подписи стали возникать вопросы, а где взять корневые сертификаты, чтобы установить в хранилища доверенных корневых сертификатов.

Это касается как хранилища сертификатов в Windows, так и хранилища сертификатов в браузерах Firefox и Google Chrome, GnuPG, LibreOffice, почтовых клиентах и даже OpenSSL. Конечно, надо было озаботиться этим при получении сертификата в УЦ и записать цепочку сертификатов на флешку. А с другой стороны у нас же цифровое общество и в любой момент должна быть возможность получить эту цепочку из сети. Как это сделать на страницах Хабра показалsimpleadmin. Однако для рядового гражданина это все же сложновато (особенно, если иметь ввиду, что абсолютное их большинство сидит на Windows): нужно иметь «какой-то» openssl, утилиту fetch, которой и у меня не оказалось на компьютере, и далеко не каждый знает, что вместо нее можно использовать wget. А сколько действий нужно выполнить. Выход конечно есть, написать скрипт, но не просто скрипт поверх openssl и иже с ним, а упакованный в самодостаточный выполняемый модуль для различных платформ.

На чем писать никаких сомнений не было – на Tcl и Python. И начинаем с Tcl и вот почему:

* охренительной вики, где есть даже игрушки (там можно подсмотреть интересное 🙂
* шпаргалки
* нормальные сборки tclkit (1.5 — 2 Мб как плата за реальную кросс-платформенность)
* и моя любимая сборка eTcl от Evolane (бережно сохранённая с умершего сайта 🙁
сохраняют высокий рейтинг Tcl/Tk в моём личном списке инструментария
и, да, wiki.tcl.tk/16867 (мелкий web-сервер с cgi на Tcl, периодически используется с завидным постоянством под tclkit)
а ещё — это просто красиво и красиво 🙂

К этому бы я добавил наличии утилиты

freewrap

, которая нам и поможет собрать автономные (standalone) утилиты для Linux и MS Windows. В результате мы будем иметь утилиту chainfromcert:

bash-4.3$ ./chainfromcert_linux64  
Copyright(C)2021 
Usage: 
chainfromcert <file with certificate> <directory for chain certificate> 
Bad usage! 
bash-4.3$

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

bash-4.3$ ./chainfromcert_linux64  ./cert_test.der /tmp
Loading file: cert_test.der 
Directory for chain: . 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2021.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2021
bash-4.3$

А теперь рассмотрим как работает утилита.

Информация о центре сертификации, выдавшем сертификат пользователю, хранится в расширении с oid-ом 1.3.6.1.5.5.7.1.1. В этом расширении может хранится как о местонахождении сертификата УЦ (oid 1.3.6.1.5.5.7.48.2), так и информация о службе OCSP УЦ (oid 1.3.6.1.5.5.7.48.1):

А информация, например, о периоде использования ключа электронной подписи хранится в расширении с oid-ом 2.5.29.16.

Для разбора сертификата и доступа к расширениям сертификата воспользуемся пакетом pki:

#!/usr/bin/tclsh -f
package require pki

Нам также потребуются пакет base64:

package require base64

Пакет pki, а также подгружаемые им пакет asn, и пакет base64 и помогут нам преобразовывать сертификаты из PEM-кодировки в DER-кодировку, разобрать ASN-структуры и собственно получить доступ к информации о местонахождении сертификатов УЦ.

Работа утилиты начинается с проверки параметров и загрузки файла с сертификатом:

proc usage {use } {
    puts "Copyright(C)  2021-2021"
    if {$use == 1} {
	puts "Usage:nchainfromcert <file with certificate> <directory for chain certificate>n"
    }
}
if {[llength $argv] != 2 } {
    usage 1
    puts "Bad usage!"
    exit
}
set file [lindex $argv 0]
if {![file exists $file]} {
    puts "File $file not exist"
    usage 1
    exit
}
puts "Loading file: $file"
set dir [lindex $argv 1]
if {![file exists $dir]} {
    puts "Dir $dir not exist"
    usage 1
    exit
}
puts "Directory for chain: $dir"
set fd [open $file]
chan configure $fd -translation binary
set data [read $fd]
close $fd
if {$data == "" } {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}

Здесь все понятно и отметим только одно – файл с сертификатом рассматривается как бинарный файл:

chan configure $fd -translation binary

Это связано с тем, что сертификат может хранится как в формате DER (двоичный код), так и в формате PEM (base64 — кодировка).

После того как файл загружен вызывается процедура chainfromcert:

set depth [chainfromcert $data $dir]

которая собственно и загружает корневые сертификаты:

proc chainfromcert {cert dir} {
    if {$cert == "" } {
	exit
    }
    set asndata [cert_to_der $cert]
    if {$asndata == "" } {
#Файл содержит все что угодно, только не сертификат
	return -1
    }
    array set cert_parse [::pki::x509::parse_cert $asndata]
    array set extcert $cert_parse(extensions)
    if {![info exists extcert(1.3.6.1.5.5.7.1.1)]} {
#В сертификате нет расширений
	return 0
    }
    set a [lindex $extcert(1.3.6.1.5.5.7.1.1) 0]
#    if {$a == "false"} {
#	puts $a
#    }
#Читаем ASN1-последовательность расширения в Hex-кодировке
    set b [lindex $extcert(1.3.6.1.5.5.7.1.1) 1]
#Переводим в двоичную кодировку
    set c [binary format H* $b]
#Sequence 1.3.6.1.5.5.7.1.1
    ::asn::asnGetSequence c c_par_first
#Цикл перебора значений в засширении 1.3.6.1.5.5.7.1.1
    while {[string length $c_par_first] > 0 } {
#Выбираем очередную последовательность (sequence)
	::asn::asnGetSequence c_par_first c_par
#Выбираем oid из последовательности
	::asn::asnGetObjectIdentifier c_par c_type
	set tas1 [::pki::_oid_number_to_name $c_type]
#Выбираем установленное значение
	::asn::asnGetContext c_par c_par_two
#Ищем oid с адресом корневого сертификата
	if {$tas1 == "1.3.6.1.5.5.7.48.2" } {
#Читаем очередной корневой сертификат
	    set certca [readca $c_par $dir]
	    if {$certca == ""} {
#Прочитать сертификат не удалось. Ищем следующую точку с сертификатом
		continue
	    } else {
		global count
#Сохраняем корневой сертификат в указанном каталоге
		set f [file join $dir [file tail $c_par]]
		set fd [open $f w]
		chan configure $fd -translation binary
		puts -nonewline $fd $certca 
		close $fd
		incr count
		puts "cert $count from $c_par"
#ПОДЫМАЕМСЯ по ЦЕПОЧКЕ СЕРТИФИКАТОВ ВВЕРХ
		chainfromcert $certca $dir
		continue
	    }
	} elseif {$tas1 == "1.3.6.1.5.5.7.48.1" } {
#	    puts "OCSP server (oid=$tas1)=$c_par"
	}
    }
# Цепочка закончилась
    return $count
}

К комментариям добавить нечего, но у нас осталась не рассмотренной процедура readca:

proc readca {url dir} {
    set cer ""
#Читаем сертификат в бинарном виде
    if {[catch {set token [http::geturl $url -binary 1]
#получаем статус выполнения функции
	set ere [http::status $token]
	if {$ere == "ok"} {
#Получаем код возврата с которым был прочитан сертификат
	    set code [http::ncode $token]
	    if {$code == 200} {
#Сертификат успешно прочитан и будет созвращен
                set cer [http::data $token]
    	    } elseif {$code == 301 || $code == 302} {
#Сертификат перемещен в другое место, получаем его 
         		set newURL [dict get [http::meta $token] Location]
#Читаем сертификат с другого сервера
          		set cer [readca $newURL $dir]
    	    } else {
#Сертификат не удалось прочитать
        	set cer ""
    	    }
        } 
    } error]} {
#Сертификат не удалось прочитать, нет узла в сети
	set cer ""
    }
    return $cer
}

Это процедура построена на использовании пакета http:

package require http

Для чтения сертификата мы используем следующую функцию:

set token [http::geturl $url -binary 1]

Назначение остальных используемых функции понятно из комментариев. Дадим только расшифровку кодов возврата для функции http::ncodel:

200 Запрос успешно выполнен
206 Запрос успешно выполнен, но удалось скачать только часть файла
301 Файл перемещен в другое место
302 Файл временно перемещен в другое место
401 Требуется аутентификация на сервере
403 Доступ к этому ресурсу запрещен
404 Указанный ресурс не может быть найден
500 Внутренняя ошибка

Осталось не рассмотренной одна процедура, а именно cert_to_der:

proc cert_to_der {data} {
    set lines [split $data n]
    set hlines 0
    set total 0
    set first 0
#Ищем PEM-сертификат в файле
    foreach line $lines {
        incr total
        if {[regexp {^-----BEGIN CERTIFICATE-----$} $line]} {
            if {$first} {
                incr total -1
                break
            } else {
                set first 1
                incr hlines
            }
        }        
        if {[regexp {^(.*):(.*)$} $line ]} {
            incr hlines
        } 
    }
    if { $first == 0 && [string range $data 0 0 ] == "0" } {
#Очень похоже на DER-кодировку "0" == 0x30 
	return $data
    }
    if {$first == 0} {return ""}
    set block [join [lrange $lines $hlines [expr {$total-1}]]]
#from PEM to DER
    set asnblock [base64::decode $block]
    return $asnblock
}

Схема процедуры очень простая. Если это PEM-файл с сертификатом («—–BEGIN CERTIFICATE—– »), то выбирается тело этого файла и преобразуется в бинаоный код:

set asnblock [base64::decode $block]

Если это не PEM-файл, то проверяется это «похожесть» на asn-кодировку (нулевой бит должен быть равен 0x30).

Вот собственно и все, осталось добавить завершающие строки:

if {$depth == -1} {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}
puts "Goodby!nLength chain=$depth"
usage 0
exit

Теперь все собираем в один файл с именем

Проверить работу этого файла можно с помощью интерпретарора tclsh:

$ tclsh ./chainfromcert.tcl cert_orlov.der /tmp 
Loading file: cert_test.der 
Directory for chain: /tmp 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2021.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2021 
$

В результате работы мы получили цепочку из двух сертификатов в каталоге /tmp.

Но мы хотели получить выполняемые модули для платформ Linux и Windowsи и чтобы пользователи не задумывались о каких-то интерпретаторах.

Для этой цели мы воспользуемся утилитой freewrapTCLSH. С помощью этой утилиты мы сделаем выполняемые модули нашей утилиты для платформ Linux и Windows как 32-х разрядных так и 64-х. Сборку утилит можно проводить для всех платформ на любой из платформ. Извините за тавтологию. Я буду собирать на linux_x86_64 (Mageia).

Для сборки потребуется:

1. Утилита freewrapTCLSH для платформы linux_x86_64;
2. Файл freewrapTCLSH с этой утилитой для каждой платформы:
— freewrapTCLSH_linux32
— freewrapTCLSH_linux64
— freewrapTCLSH_win32
— freewrapTCLSH_win64
3. Исходный файл нашей утилиты: chainfromcert.tcl

Итак, собираемый выполняемый файл chainfromcerty_linuxx86 для платформы Linux x86:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_linux32 –o chainfromcerty_linuxx86
$

Сборка утилиты для платформы Windows 64-х битного выглядит так:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_win64 –o chainfromcerty_win64.exe
$

И т.д. Утилиты готовы к использованию. Все необходимое для их работы они вобрали в себя.

Аналогичным образом пишется код и на Python-е.

В ближайшие дни я думаю дополнить пакет fsb795 (а он написан на Python-е) функцией получения цепочки корневых сертификатов.

Данный документ дает краткое описание
стандарта 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.

Дополнения 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.

Для идентификации без использования
открытого ключа, можно также
использовать монотонно возрастающую
последовательность целых чисел.
Для сертификатов конечного
пользователя, данное дополнение
используется для идентификации
приложением различных сертификатов
содержащих определенный открытый ключ.
Если конечный пользователь обладает
несколькими сертификатами, особенно от
разных ЦС, данное дополнение позволяет
быстро определить требуемый сертификат.
Для этих целей данное дополнение должно
добавлять во все сертификаты конечных
пользователей.
Значение данного дополнения для
сертификатов конечных пользователей
должно формироваться из значения
открытого ключа способом описанным выше.
Данное дополнение служит для определения
взаимосвязей между различными
объектами на всем сроке существования
открытого ключа (запрос, сертификат,
сообщение о компрометации, СОС).

Область применения ключа

Данное дополнение определяет область
применения секретного ключа,
соответствующего открытому,
содержащемуся в сертификате.

Таблица. Области применения
ключа

Расширенная область применения ключа

Данное дополнение (Extended keyUsage)
предназначено для задания
дополнительных областей применения
ключа по требованиям прикладного ПО.
Значение Область применения ключа (KeyPurposeId)
данного дополнения может быть
определена любой организацией в
зависимости от конкретных целей.
Идентификатор объекта, для
идентификации области применения
должен назначаться в соответствии с IANA
или ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1.

Срок действия секретного ключа

Данное дополнение позволяет Издателю
сертификата задать различные сроки
действия секретного и сертификата.
Дополнение содержит два опциональных
компонента: notBefore и notAfter. Секретный
ключ, соответствующий открытому в
сертификате, не должен быть использован
до или после времен, указанных
соответствующими компонентами. ЦС не
должен формировать сертификат, в
котором не указан не один из компонентов.

Регламенты использования сертификата

Данное дополнение представляет собой
последовательность, состоящую из одного
или нескольких информаторов
регламента (PolicyInformation), каждый из
которых содержит идентификатор
объекта (OID) и опциональный квалификатор. 
Данный информатор регламента отображает
регламент, с учетом которого сертификат
был издан и цели, для которых сертификат
может быть использован. Опциональный квалификатор,
который может присутствовать, не
предусмотрен для целей изменения
регламента, определенного информатором.

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

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

Таблица. Информация о
Регламенте сертификата

Соответствие регламентов

Данное дополнение предназначено для
использования в сертификатах ЦС. Оно
содержит список парных Идентификаторов
Объектов (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}

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

Поля с идентификаторами 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.