30549

Сетевая модель доверительных отношений

Доклад

Математика и математический анализ

Вышестоящий центр может передать подчиненному C часть своих функций по выпуску сертификатов. Оконечный центр C предназначен для выдачи сертификатов пользователям PKI в то время как промежуточный C рекомендуется использовать только для выдачи сертификатов подчиненным ему центрам C. В модели P2P существует два метода установления доверительных отношений: с помощью списков сертификатов заслуживающих доверия Сertificte Trust List CTL и кросссертификатов.inf можно устанавливать параметры регулируемых доверительных отношений для сертификатов C...

Русский

2013-08-24

189.15 KB

6 чел.

Доска

Иерархическая модель

Сетевая модель

Выступление

В основе технологии управления доверительными отношениями как между центрами CA (Certification Authority), так и между пользователями инфраструктуры PKI и центрами сертификации лежит понятие модели доверия PKI.

Иерархическая модель PKI, которая представляет собой дерево центров CA, обычно используется для установления доверительных отношений в инфраструктуре PKI в пределах одной организации. Те компании, организационная структура которых имеет ярко выраженный иерархический характер, легко вписываются в модель этого типа.

В данной модели между центрами CA, находящимися на различных ярусах иерархии, в явном виде существуют отношения типа «вышестоящий — подчиненный». На вершине иерархии располагается корневой центр CA, который является в этом случае центром доверия. Внутри данной иерархии только сам корневой центр CA имеет право подписывать собственный сертификат, что исключает для других членов иерархии возможность претендовать на то, чтобы стать корневым CA. Это обусловлено тем, что только корневой центр CA знает свой секретный ключ и является его единственным владельцем. Корневой центр сертификации выдает сертификаты центрам CA первого яруса (располагающимся на уровень ниже по иерархии), те в свою очередь сертифицируют центры CA второго яруса и т. д.

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

Сетевая модель доверительных отношений

В сетевой модели доверительных отношений (также называемой моделью «точка-точка» (P2P) или распределенной моделью доверительных отношений) между центрами CA отсутствуют отношения типа «вышестоящий — подчиненный», здесь все центры сертификации рассматриваются как равноправные точки. Данная модель обычно используется в PKI при установлении доверительных отношений между организациями. В модели P2P существует два метода установления доверительных отношений: с помощью списков сертификатов, заслуживающих доверия (Сertificate Trust List, CTL), и кросссертификатов. Инфраструктура Windows 2003 PKI поддерживает оба метода, в Windows 2000 PKI поддерживаются только списки CTL.

Регулируемые доверительные отношения

В рамках инфраструктуры PKI среды Windows 2003 реализована поддержка регулируемых доверительных отношений (в Microsoft такой тип отношений называют «ограниченное подчинение»). С помощью этой технологии администраторы центров CA могут управлять доверительными отношениями между вышестоящим центром CA и его подчиненными центрами (для иерархической модели) или воздействовать на отношения между центрами-точками (для сетевой модели). Возможность регулирования отношений доверия, имеющаяся в PKI, придает им некоторое сходство с доверительными отношениями в реальной жизни: они редко бывают полными и обычно зависят от ряда условий.

Настройка регулируемых доверительных отношений

Для установки параметров регулируемых доверительных отношений в инфраструктуре Windows 2003 PKI имеется три средства: конфигурационный файл capolicy.inf, конфигурационный файл policy.inf и оснастка Certificate Templates консоли MMC.

В процессе установки центра CA с помощью файла capolicy.inf можно устанавливать параметры регулируемых доверительных отношений для сертификатов CA инфраструктуры PKI, а также изменять другие параметры настройки центра CA. Например, можно задать местонахождение узлов распространения списков сертификатов, подлежащих аннулированию (Certificate Revocation List (CRL) Distribution Points) и узлов Authority Information Access (AIA). Проверка содержимого файла capolicy.inf на наличие параметров регулируемых доверительных отношений производится при установке центра CA, а также при каждом обновлении его сертификата. Данный файл следует хранить в каталоге %systemroot% того компьютера, на который устанавливается центр CA, причем имя этого файла изменять нельзя. В файле capolicy.inf можно задавать только параметры ограничения типа basic и issuance policy.

Процедура сличения

В процессе проверки подлинности сертификата для него выполняются процедуры сличения по следующим критериям: цифровая подпись (digital signature), параметры отношений доверия (trust), временные параметры (time), информация об аннулировании сертификата (revocation) и параметры формата (formatting). Если выясняется, что сертификат не соответствует требованиям хотя бы одного из этих критериев, то он считается недействительным. При сличении цифровой подписи программа проверки подлинности с помощью заслуживающего доверия открытого ключа проверяет подлинность цифровой подписи, добавленной в сертификат выдавшим его центром Certificate Authority (CA). В качестве ключа используется открытый ключ выдавшего сертификат центра CA либо другого центра, входящего в цепочку сертификатов в соответствии с иерархической моделью доверительных отношений.

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

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

Certificate Revocation List (CLR) - список сертификатов, аннулированных раньше срока их истечения.

Дополнительно

Иерархическая модель PKI

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

Установление иерархических доверительных отношений между вышестоящим и подчиненным центрами CA осуществляется в процессе развертывания Windows 2003 CA. В показанном на экране диалоговом окне CA Type программы Windows Components Wizard можно выбрать тип устанавливаемого центра CA: корневой (root CA) или подчиненный (subordinate CA). Если строится иерархическая структура центров CA, то при установке корневых и промежуточных (т. е. не оконечных) центров следует применять тип установки standalone (независимый), что упростит использование этих центров в автономном режиме. Оконечные центры лучше устанавливать как Windows 2003 enterprise CA, при этом они смогут интегрироваться в структуру Active Directory (AD).

Сетевая модель доверительных отношений

Список CTL представляет собой заверенный перечень сертификатов, которым доверяет центр CA. Администратор PKI осуществляет централизованное управление этим списком и распространяет его по всем клиентам инфраструктуры PKI организации. Списки CTL могут быть определены с помощью установки параметров объекта групповой политики (GPO). В инфраструктурах PKI систем Windows 2003 и Windows 2000 можно задавать срок действия CTL, а также ограничивать его применение определенным набором приложений, работающих с PKI.

Кросс-сертификация представляет собой не что иное, как возможность обмена сертификатами между двумя центрами CA,которые являются точками в сетевой модели доверительных отношений, т. е. один центр CA может выдавать сертификат другому центру и, соответственно, получать от него сертификат. При кросс-сертификации допускаются как односторонние, так и двусторонние доверительные отношения (т. е. когда оба CA могут сертифицировать друг друга). Пример построения доверительных отношений между организациями в соответствии с сетевой моделью показан на рис. на доске.

В клиентах PKI систем Windows 2003 и Windows XP реализована поддержка механизмов обнаружения путей доверия и отслеживания связей, необходимых для построения сетевой модели доверительных отношений с несколькими связями кросс-сертификации. В клиентах PKI системы Windows 2000 такие механизмы не поддерживаются. При проверке подлинности сертификата, выданного центром CA, который является точкой сетевой модели, программное обеспечение PKI клиента пытается выстроить путь доверия, который связывает центр CA, выдавший сертификат, с центром доверия локального CA.

В отличие от иерархических доверительных отношений, доверительные отношения на базе кросс-сертификатов могут быть установлены в любой момент после установки центра CA. Следует отметить, что доверительные отношения на базе кросс-сертификатов не могут устанавливаться через графический интерфейс Windows PKI, для этого придется воспользоваться утилитой командной строки certreq.exe. Инструкции по установке доверительных отношений на базе кросс-сертификатов содержатся в документации на Windows 2003 и в официальных документах Microsoft по адресу: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/ws03qswp.mspx.

Регулируемые доверительные отношения

Базовые ограничения. Эти параметры регулирования основываются на расширениях сертификата X.509, называемых Basic Constraints и содержащих поле с именем pathLenConstraint (или path-length constraint). Эти поля можно использовать только в том случае, если в поле СА расширения X.509 Basic Constraint сертификата установлено значение true, что имеет место только в сертификатах центров CA. С помощью параметра path-length constraint задается максимально допустимое количество сертификатов, выпущенных независимыми центрами CA, которые могут следовать в пути сертификации за данным сертификатом. Таким образом, изменяя значение данного параметра, можно ограничивать длину цепочки сертификатов, образующих путь сертификации.

Рисунок 3. Пример базовых ограничений

На рис. 3 показано два примера иерархических отношений доверия: Config 1 и Config 2. В примере Config 1 установка параметра базового ограничения в сертификате подчиненного центра CA уровня 1 ограничивает длину пути сертификата до 1. В результате центр CA, расположенный на уровень ниже, сможет выдавать пользовательские сертификаты, но он лишен возможности выдавать сертификаты центрам CA. В примере Config 2 аналогичный результат достигается путем добавления параметра длины пути, равного 2, в сертификат корневого центра CA. В этом случае программное обеспечение PKI автоматически добавит параметр длины пути, равный 1, во все сертификаты подчиненных CA, которые были выданы корневым центром.

Ограничения по именам. Расширение сертификата типа ограничения по именам может устанавливаться только для сертификатов центров CA. Данная возможность позволяет ограничить количество субъектов, которым могут выдавать сертификаты подчиненные центры CA или СA, работающие по кросс-сертификатам. С помощью расширений типа ограничения по именам можно задавать то пространство имен, в пределах которого должны находиться имена и дублирующие имена или IP-адреса субъектов, посылающих запросы на сертификацию. Параметры ограничения доверия данного типа размещаются в расширении Name Constraints сертификата центра CA. В соответствии с RFC 3280, расширение сертификата типа Name Constraint определяет то пространство имен, в пределах которого должны находиться имена всех субъектов в последовательности сертификатов, формирующих путь сертификации. Следовательно, подчиненный центр CA может только ужесточать (но не ослаблять) те установки пространства имен, которые он получает от вышестоящего центра. Например, если подчиненному центру CA разрешено выдавать сертификаты только пользователям домена DNS research.hp.com, отсюда следует, что он не сможет выдать сертификат для подчиненного центра CA, позволяющий тому выдавать пользовательские сертификаты в домене DNS hp.com.

Рисунок 4. Пример ограничения по именам

Если рассмотреть иерархическую модель доверительных отношений, показанную на рис. 4, можно увидеть, что параметры ограничения по именам содержат как правила исключения, так и правила включения. При проверке подлинности параметров ограничения по именам правила исключения всегда имеют преимущества перед правилами включения. В рассматриваемом примере в установках параметра ограничения по именам введено исключение для пользовательского UPN-имени @abc.com и разрешения для имен DNS .hp.com и .compaq.com. Соответственно, если центр CA 1 принимает запрос на сертификат для пользователя joe@abc.com, то такой запрос будет отклонен. Если же приходит запрос для webserver1.hp.com, то в этом случае центр CA 1 принимает данный запрос. Пространство имен подчиненного центра CA 2 является еще более ограниченным: он может выдавать сертификаты только для имен DNS из пространства .compaq.com. Таким образом, если на CA 2 поступает запрос сертификата для webserver2 .hp.com, то этот запрос отклоняется, в то время как запрос, поступивший на CA 2 для mail.compaq .com, будет им принят.

Ограничения по политике выдачи сертификатов. В ограничениях данного типа задаются условия, которые должны выполняться при выдаче сертификатов. В сертификате среды Windows 2003 в качестве идентификатора политики ограничения по выдаче применяется соответствующий идентификатор объекта (OID), который хранится в расширении сертификата Certificate policies.

При добавлении в сертификат центра CA параметров ограничения по выдаче определяется набор правил, которые будут включаться в каждый сертификат, выданный этим центром. Эти параметры могут быть включены, в частности, в сертификаты тех центров CA, работа с которыми ведется по кросс-сертификатам, за счет чего можно ограничивать степень доверия к сертификатам, выданным этими центрами. Возможность применения расширений ограничений по выдаче зависит от наличия логики проверки подлинности цепочки сертификатов. Данная логика поддерживается только в Windows 2003 и Windows XP.

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

В Windows 2003 PKI имеется набор предустановленных политик ограничения по выдаче, перечень которых вместе с их идентификаторами OID и описаниями функций приведен в табл. 2. Переменные a, b, c и d, присутствующие в идентификаторах OID политик с уровнями защищенности low (низкий), medium (средний) и high (высокий), представляют собой случайным образом генерируемые величины, которые являются уникальными в пределах каждого леса Windows 2003. При необходимости могут быть разработаны и собственные политики, отвечающие требованиям конкретной среды PKI или приложения. На рис. 5 показан пример установки политики ограничения по выдаче в сертификате конечного пользователя. В данном случае определена политика с низким уровнем защищенности (low assurance), которая наследуется от оконечного центра CA на уровне 1. Если попытаться задействовать данный сертификат для работы с PKIприложением, требующим применения политики с высоким уровнем защищенности, данный сертификат будет отклонен, поскольку он может применяться только для приложений с низким уровнем защищенности.

Рисунок 5. Ограничения по выдаче сертификатов  

Ограничения по политике приложений. С помощью параметров регулирования степени доверия типа ограничения по политике приложений можно задать круг приложений, для которых могут использоваться сертификаты. Данные параметры могут задаваться как в сертификатах центров CA (для иерархической модели или модели с кросс-сертификацией), так и для сертификатов конечных пользователей. Здесь, как и в предыдущем случае, для идентификации политики применяется ее соответствующий идентификатор объекта (OID), который хранится в расширении сертификата Application policies. В сертификатах версии 2, которые впервые появились в Windows 2003, политика для приложений реализует ту же функцию, что и расширение сертификата Extended Key Usage (EKU) в среде Windows 2000. Сертификаты версии 2 выпускаются корпоративным центром и строятся на базе шаблонов сертификатов версии 2. Для того чтобы обеспечить совместимость с предыдущими версиями в центрах CA на базе Windows 2003, а также в клиентах Windows 2003 и Windows XP, сохранены возможности работы с расширениями сертификатов EKU.

Как отмечалось выше, установку параметров политики приложений можно выполнять как в сертификатах пользователей, так и в сертификатах центров CA. Если данная установка выполняется в сертификате пользователя, то ограничивается количество приложений, для которых может применяться данный сертификат. Если же эта установка выполняется в сертификате CA, тогда установленная политика будет распространена на все сертификаты, выпущенные данным центром, включая сертификаты конечных пользователей и центров CA. Таким образом, будет ограничен набор используемых приложений для всех этих сертификатов. Установка данной политики в сертификате центра CA также приведет к сокращению количества типов сертификатов, которые могут выпускаться этим центром. Для корпоративного центра CA установки данной политики имеют более высокий приоритет, чем настройки шаблонов сертификатов данного центра, хранящихся в его контейнере Certificate Templates. Например, если нужно предоставить возможность подчиненному центру CA выдавать сертификаты конечным пользователям, следует убедиться, что были добавлены идентификаторы политики приложений OID для шифрующей файловой системы Encrypting File System (EFS), защищенной почты и аутентификации клиента. Все эти три типа политик приложений предусматриваются шаблоном User.

Политики приложений, устанавливаемые в кросс-сертификатах, предназначены для ограничения набора приложений, доступных для тех сертификатов, в цепочке сертификации которых есть кросс-сертификаты. При этом ответственность за реализацию данной политики лежит на программном обеспечении, выполняющем проверку подлинности цепочки сертификатов. Отметим, что, как и в предыдущем случае, программная реализация проверки политики приложений имеется только в системах Windows 2003 и Windows XP. На рис. 6 показаны результаты установки политики приложений в сертификатах центров CA. На рисунке видно, что в сертификатах подчиненных центров CA 1 и CA 2 была установлена политика приложений. В результате подчиненный центр CA 1 может принимать запросы на сертификаты для электронной почты и для Secure Sockets Layer (SSL), в то время как подчиненный центр CA 2 принимает запросы для сертификатов электронной почты, но отклоняет запросы сертификатов SSL.

Рисунок 6. Пример ограничения по именам

Настройка регулируемых доверительных отношений

Для установки параметров регулируемых доверительных отношений в инфраструктуре Windows 2003 PKI имеется три средства: конфигурационный файл capolicy.inf, конфигурационный файл policy.inf и оснастка Certificate Templates консоли MMC.

В процессе установки центра CA с помощью файла capolicy.inf можно устанавливать параметры регулируемых доверительных отношений для сертификатов CA инфраструктуры PKI, а также изменять другие параметры настройки центра CA. Например, можно задать местонахождение узлов распространения списков сертификатов, подлежащих аннулированию (Certificate Revocation List (CRL) Distribution Points) и узлов Authority Information Access (AIA). Проверка содержимого файла capolicy.inf на наличие параметров регулируемых доверительных отношений производится при установке центра CA, а также при каждом обновлении его сертификата. Данный файл следует хранить в каталоге %systemroot% того компьютера, на который устанавливается центр CA, причем имя этого файла изменять нельзя. В файле capolicy.inf можно задавать только параметры ограничения типа basic и issuance policy.

С помощью конфигурационного файла policy.inf можно определять те параметры ограничения степени доверия, которые записываются в файл запросов сертификатов центра CA (утилита Certreq использует данный файл в качестве параметра). Файл policy.inf предоставляет наиболее полные возможности конфигурирования отношений с регулируемой степенью доверия; здесь, в отличие от файла capolicy.inf, могут настраиваться параметры регулирования степени доверия всех категорий. Отметим также, что, в противоположность файлу capolicy.inf, имя файла policy.inf может быть изменено.

Через оснастку Certificate Templates могут создаваться, редактироваться и удаляться шаблоны сертификатов. Шаблоны сертификатов определяют свойства сертификатов (в том числе относящиеся к регулируемым доверительным отношениям), выдаваемых центрами сертификации Windows CA. Шаблоны сертификатов версии 2 предусматривают редактирование, шаблоны версии 1 не редактируются. Следует отметить, что редактирование шаблонов сертификатов предоставляет менее полные возможности настройки регулируемых доверительных отношений, чем работа с файлом policy.inf: с помощью шаблонов сертификатов могут настраиваться только те параметры ограничения степени доверия, которые относятся к категориям basic, application policy и issuance policy.

Гибкость управления доверием в PKI

Принципы доверия являются фундаментальной концепцией инфраструктуры PKI. Расширенные возможности доверительных отношений, реализованные в Windows 2003 PKI, с одной стороны, делают данную инфраструктуру более мощной и гибкой, а с другой — вносят дополнительную сложность в процессы построения и администрирования доверительных отношений. Тем не менее на данный момент не существует какого-либо другого защищенного протокола или технологии с аналогичными возможностями работы с доверительными отношениями. В следующей статье будут рассмотрены методики управления доверительными отношениями на стороне пользователя инфраструктуры Windows PKI.

Стандартная процедура обработки цепочки сертификатов

Что такое цепочка сертификатов и почему ее следует обрабатывать в процессе проверки подлинности сертификата? С помощью построения цепочки можно организовать проверку подлинности всех сертификатов, с которыми связан данный сертификат. Для того чтобы разобраться в том, что представляет собой цепочка сертификатов, обратимся к иерархической модели доверительных отношений в инфраструктуре PKI. В данной модели  цепочка сертификатов каждого пользователя состоит из сертификатов всех центров CA, которые образуют в пределах данной иерархии путь от пользователя до корневого (root) центра CA. При использовании иерархической модели доверительных отношений каждый сертификат содержит указатель на родительский (или выдавший сертификат) центр CA, который хранится в поле issuer сертификата X.509. На рис. 1 показан пример цепочки для пользовательского сертификата, выданного центром CA при наличии двухуровневой иерархии в инфраструктуре PKI. Рис. 1 иллюстрирует простейший пример использования параметров certificate subject (субъект) и certificate issuer (издатель сертификата). В данном примере субъектом пользовательского сертификата является пользователь, а издателем сертификата — промежуточный центр CA. В сертификате промежуточного центра субъектом является сам этот центр, издателем же в данном случае будет корневой CA. В иерархической модели доверительных отношений корневой центр CA всегда сам подписывает свой сертификат, поэтому для своего сертификата он является как субъектом, так и издателем сертификата.

Обработка цепочки выполняется программой проверки подлинности сертификатов. Данный процесс разделяется на две составляющие: построение цепочки сертификатов и проверка ее подлинности.

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

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

Для идентификации сертификата центра CA во время процедуры проверки подлинности цепочки используется расширение Authority Key Identifier (AKI) проверяемого сертификата. В поле AKI содержится информация следующих типов.

Имя центра, выдавшего сертификат и серийный номер сертификата данного центра. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя поля Serial number и Subject. Данный метод идентификации сертификата называется строгим совпадением.

Идентификатор открытого ключа (KeyID) сертификата центра, выдавшего проверяемый сертификат. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя расширение сертификата Subject Key Identifier (SKI), в котором хранится уникальный идентификатор открытого ключа сертификата субъекта. Данный метод идентификации сертификата называется совпадением ключей.

Если в проверяемом сертификате поле AKI отсутствует, программа проверки подлинности пытается идентифицировать сертификат выдавшего центра CA с помощью проверки совпадения имени, взятого из поля Issuer проверяемого сертификата, с содержимым поля Subject сертификата. Данный метод идентификации сертификата называется совпадением имен.

В тех случаях когда проверяемый сертификат недоступен локально, имеющиеся в Windows программные средства проверки подлинности используют расширение Authority Information Access (AIA), с тем чтобы получить копию сертификата путем его загрузки по сети с соответствующего узла. Для этого используется поле AIA, которое содержит указатель на узел хранения сертификатов центров CA для протоколов FTP, HTTP, Lightweight Directory Access Protocol (LDAP) или указатель на соответствующий файловый ресурс. Если поле AIA содержит несколько ссылок, программные средства проверки подлинности пытаются задействовать все эти ссылки в порядке их перечисления в данном поле. Все сертификаты, которые загружаются с использованием поля AIA, кэшируются программой проверки в профиле пользователя PKI на локальном диске (а именно в папке Documents and SettingsusernameLocal SettingsTemporary Internet Files), а также в локальном хранилище сертификатов пользователя.

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

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

Если при загрузке сертификата используется Web-интерфейс центра CA систем Windows 2003 или Windows 2000 Server, то в этом случае можно выбрать загрузку только самого сертификата либо загрузку данного сертификата совместно со всеми сертификатами, образующими цепочку. Возможность загрузки цепочки сертификатов иногда бывает весьма полезной, например если для работы используется переносной компьютер. В этом случае все сертификаты цепочки будут доступны для программы проверки подлинности даже тогда, когда пользователь находится в дороге.