Инфраструктура
Открытых Ключей
операционной системы Microsoft Windows 2000
В операционной системе Microsoft® Windows® 2000 в полном объеме реализована инфраструктура открытых ключей (PKI – Public Key Infrastructure). Эта инфраструктура представляет собой интегрированный набор служб и средств администрирования для создания и развертывания приложений, применяющих криптографию с открытыми ключами, а также для управления ими. Она позволяет разработчикам в среде Windows использовать механизмы безопасности как на основе шифрования с общим секретным ключом сессии (shared-secret security), так и на основе криптографии с открытым ключом. Предприятия также получают возможность управлять средой и приложениями с помощью согласованных между собой средств и политик.
Криптография –
это комплексная наука о защите данных. Криптографические алгоритмы используются
для шифрования открытый текст (plaintext) с использованием ключа
шифрования (encryption key), в результате
чего получаются зашифрованные данные (ciphertext). Зашифрованный по надежному криптографическому
алгоритму текст практически невозможно расшифровать без дополнительных данных,
которые называются ключом расшифрования (decryption key).
В
криптографии с симметричными ключами (symmetric
key), для шифрования и расшифрования используется один и тот же
секретный ключ (secret key), то есть ключ шифрования совпадает с
ключом расшифрования. Стороны могут передавать друг другу данные, зашифрованные
секретным ключом, только после того, как они обменяются этим общим ключом.
В
отличие от шифрования с секретным ключом фундаментальным свойством шифрования
с открытым ключом является различие между ключом шифрования и ключом
расшифрования. Открытый ключ позволяет зашифровать открытый текст, но не позволяет
расшифровать его. В этом смысле открытый ключ можно назвать односторонним
(one-way). Чтобы расшифровать текст, нужен ключ расшифрования, который отличается
от ключа шифрования, хотя и связан с ним. Таким образом, при шифровании с открытым
ключом у каждого пользователя должно быть два ключа – открытый (public) и личный
(private) – секретный ключ.
Если открытый ключ сделать общедоступным, пользователи смогут отправлять вам
зашифрованные с ним данные, которые только
вы будете способны расшифровать с помощью своего личного секретного ключа. С
помощью личного ключа вы также можете преобразовать отправляемые данные
таким образом, что пользователи смогут удостовериться в том, что эти данные
были отправлены именно вами, а не кем-то
другим. Эта возможность служит основой цифровых подписей, которые подробнее
обсуждаются далее.
Различие
ключей – открытого и личного –
в криптографии с открытыми ключами позволило
создать следующие технологии: электронные цифровые подписи, распределенная проверка
подлинности, согласование общего секретного
ключа сессии, шифрование больших объемов данных без предварительного
обмена общим секретным ключом.
В
настоящее время хорошо известен целый ряд алгоритмов шифрования с открытым
ключом. Некоторые алгоритмы, например RSA (Rivest-Shamir-Adleman) и ECC
(Elliptic Curve Cryptography), универсальны, они поддерживают все перечисленные
выше операции. Другие алгоритмы более специализированы и поддерживают не все
возможности. К их числу относятся:
·
российский алгоритм электронной цифровой подписи ГОСТ Р 34.10‑94;
·
алгоритм электронной цифровой
подписи DSA (Digital Signature Algorithm входящий в принятый в США государственный
стандарт цифровой подписи Digital Signature Standard, FIPS 186);
·
алгоритм
DH (Diffie-Hellman), применяемый
для выработки общего секретного ключа сессии.
Далее
кратко описываются принципы использования криптографии с открытыми ключами.
Традиционно для иллюстрации криптографических алгоритмов используются условные
пользователи: Алиса и Боб. Подразумевается, что они могут обмениваться информацией,
но не имеют предварительно распределенных общих секретных ключей.
Создание
и проверка электронных цифровых
подписей (digital signature) – это, вероятно, самый
интересный аспект криптографии с открытыми ключами. Основой электронной цифровой
подписи является математическое преобразование подписываемых
(signed) данных с использованием
личного секретного ключа и выполнением следующих условий.
·
Создать
электронную цифровую подпись можно только с использованием личного секретного
ключа.
·
Проверить действительность электронной цифровой подписи может любой, имеющий доступ к соответствующему
открытому ключу.
·
Любое изменение подписанных данных (даже изменение всего одного бита
в большом файле) делает электронную цифровую
подпись недействительной.
Электронную
цифровую подпись, как и любые другие данные, можно передавать вместе
с подписанными, то есть защищенными ею данными. Например, Боб может создать
подписанное сообщение электронной почты и
отправить текст сообщения вместе с подписью
Алисе, предоставив ей возможность удостовериться в подлинности отправителя
этого сообщения. Кроме того, цифровая подпись позволяет убедиться в том, что
данные при передаче адресату не были изменены (случайно или преднамеренно).
Криптография
с открытыми ключами обеспечивает надежные службы распределенной
аутентификации.
Если Алиса получила от Боба данные и отправила ему зашифрованный с его открытым
ключом запрос на подтверждение подлинности, то Боб сможет расшифровать его и
вернуть Алисе расшифрованный запрос, подтвердив, что он воспользовался личным
секретным ключом, связанным именно с тем открытым ключом, с помощью которого
Алиса зашифровала свой запрос. Алиса также может
отправить Бобу запрос открытым
текстом. В этом случает, Боб отвечает на ее
запрос, подписав свое сообщение электронной цифровой подписью. Затем Алиса проверяет
подпись Боба с помощью его открытого ключа и удостоверяется в том, что Боб действительно
имеет соответствующий личный секретный ключ. Такой запрос делает полученное
Алисой сообщение уникальным и исключает возможность злоупотреблений со стороны
посторонних лиц. Описанная схема называется протоколом
доказательства владения (proof-of-possession),
поскольку отправитель доказывает, что он владеет требуемым для расшифрования
и создания электронной цифровой подписи личным секретным ключом.
Криптография
с открытыми ключами также позволяет двум сторонам согласовать общий секретный
ключ сессии при обмене информацией через незащищенные каналы связи. Схема выработки
общего ключа сессии выглядит следующим образом. Сначала Алиса и Боб генерируют
по одному случайному числу, которые используются как половины их общего секретного
ключа. Затем Боб отправляет Алисе свою половину секретного ключа, зашифрованную
с ее открытым ключом. Алиса отправляет Бобу свою половину, зашифрованную с его
открытым ключом. Каждая из сторон расшифровывает полученное сообщение с недостающей
половиной секретного ключа, и создает из этих двух половин общий секретный ключ.
Выполнив такой протокол, стороны могут пользоваться общим секретным ключом для
шифрования последующих сообщений.
Технология
шифрования с открытым ключом позволяет
шифровать большие объемы данных в том случае, если у обменивающихся информацией
сторон нет общего ключа. Существующие алгоритмы шифрования с открытым
ключом требуют значительно больше вычислительных ресурсов, чем симметричные
алгоритмы, поэтому они неудобны для шифрования больших объемов данных. Однако можно реализовать комбинированный
подход с использованием, как симметричного шифрования, так и шифрования с открытым
ключом.
Сначала
выбирается алгоритм шифрования с секретным ключом (ГОСТ 28147-89, DES и т. п.)
затем создается случайный сеансовый
ключ (random session key), который будет использоваться для шифрования данных.
Боб шифрует этот ключ сеанса, используя открытый ключ Алисы. Затем он отправляет
Алисе зашифрованный ключ и зашифрованные данные. Своим личным ключом Алиса расшифровывает
ключ сеанса и использует его для расшифрования данных.
Обмениваясь
сообщениями, зашифрованными симметричным секретным ключом, Алиса и Бобдоверяют
своему общему секретному ключу, потому что они создали его или
обменялись им безопасным способом, а также условились надежно хранить
этот ключ, чтобы исключить доступ к нему
посторонних лиц. При использовании шифрования c открытым ключом Алисе
и Бобу нужно защищать только свои личные секретные ключи. А открытые ключи им
нужно использовать совместно. Хранить их в секрете нет необходимости, нужна
лишь возможность идентифицировать открытый ключ другой стороны. Поэтому для
применения шифрования c открытым ключом критическое значение имеет доверие к
соответствию между известным субъектом и его открытым ключом.
Алиса
может доверять открытому ключу Боба, если Боб передал ей ключ безопасным способом.
Но безопасность передачи обеспечивается только защищенными средствами связи.
Более вероятно, что Алиса получила открытый ключ Боба с помощью незащищенного
средства связи (например, из общего каталога), поэтому нужен механизм, который
может обеспечить Алисе уверенность в том, что имеющийся у нее открытый ключ
действительно принадлежит Бобу, а не кому-либо другому. Один их таких механизмов
основан на сертификатах (certificate),
выдаваемых центром сертификации (certification
authority).
Сертификаты
обеспечивают механизм надежной связи между открытым ключом и
субъектом, которому принадлежит соответствующий личный ключ. Сертификат –
это цифровой документ, который содержит открытый
ключ субъекта (subject public key)
и подписан электронной цифровой подписью его издателя
(issuer). Сертификат также содержит
сведения об владельце открытого ключа, например, информацию, которая
его дополнительно идентифицирует. Таким образом, выдавая сертификат, издатель
удостоверяет подлинность связи между открытым ключом субъекта и информацией,
его идентифицирующей.
В
настоящее время наиболее часто используются сертификаты на основе стандарта
Международного союза телекоммуникаций ITU-T X.509 версии 3 и рекомендаций IETF
(Internet Engineering Task Force) RFC 2459. Эта базовая технология, используемая
в инфраструктуре PKI открытых
ключей операционной
системы Windows 2000. Это не единственный вид сертификатов. Например, система
защиты сообщений электронной почты PGP (Pretty Good Privacy) использует свою
специфическую форму сертификатов.
Центр
сертификации (ЦС) – это служба, которая выдает сертификаты.
Центр сертификации является гарантом связи между открытым ключом субъекта и
содержащейся в сертификате информацией по идентификации этого субъекта. Различные
ЦС устанавливают и гарантируют эту связь различными способами, поэтому прежде
чем доверять сертификатам того или иного ЦС, следует ознакомиться с его политикой
и регламентом.
Когда
Алиса получает подписанное сообщение, у нее возникает важный вопрос – можно
ли этой подписи доверять? Иными словами –
действительно ли эта подпись принадлежит отправителю сообщения? Алиса может
проверить целостность подписи с помощью известного ей открытого ключа отправителя
и криптографических алгоритмов. Однако при этом Алиса должна быть уверена в
том, что использованный ею для проверки открытый ключ действительно принадлежит
тому субъекту, именем которого подписано сообщение. Если у Алисы нет прямого
доказательства, что открытый ключ принадлежит Бобу, то ей надо получить хотя
бы достаточно веское подтверждение этого.
Если
Алиса сможет найти сертификат открытого ключа Боба, выданный тем центром сертификации,
которому она доверяет, то она получит убедительное подтверждение того, что открытый
ключ Боба действительно принадлежит Бобу. Итак, у Алисы появится веское
основание полагать, что открытый ключ принадлежит именно Бобу, если она найдет
сертификат, который:
·
имеет действительную с криптографической точки зрения подпись его издателя;
·
подтверждает связь между именем Боб и открытым ключом Боба;
·
выдан центром сертификации, которому Алиса доверяет.
Если
Алиса найдет такой сертификат открытого ключа Боба, то она сможет проверить
подлинность этого сертификата с помощью открытого ключа центра сертификации.
Однако теперь у Алисы возникает следующий вопрос. Как убедиться в том, что этот
открытый ключ действительно принадлежит данному центру сертификации? Алисе нужно
найти сертификат, удостоверяющий подлинность этого центра сертификации.
Таким
образом в процессе проверки сертификата Алиса продвигается по цепочке
сертификатов (certification path). В конце цепочки
сертификатов, ведущей от сертификата открытого
ключа Боба через ряд центров сертификации, находится сертификат, выданный
тем ЦС, которому Алиса полностью доверяет. Такой сертификат называется доверенным
корневым сертификатом (trusted root certificate), поскольку он образует
в иерархии связей «открытые ключи – личность» корень (самый верхний узел), который Алиса считает надежным (см. раздел
4.1 «Иерархия сертификатов»). Если
Алиса явно решит доверять этому доверенному корневому сертификату, то она неявно
будет доверять всем сертификатам, выданным доверенным корневым сертификатом
и всеми сертифицированными им ЦС.
Набор доверенных корневых сертификатов, которым Алиса доверяет явно – это единственная информация, которую Алиса должна получить надежным способом. На этом наборе сертификатов базируется ее система доверия и обоснование надежности инфраструктуры открытых ключей.
Укрупненная
схема компонентов инфраструктуры открытых ключей операционной
системы Windows 2000
показана на рис. 1. Это логическая схема, не связанная с реальными серверами.
На практике многие функции могут быть совмещены в системе с одним сервером.
Главный элемент инфраструктуры открытого ключа – службы сертификации Microsoft
Certificate Services. Они позволяют развернуть на предприятии один или несколько
центров сертификации (ЦС). ЦС могут быть интегрированы со службой
каталогов Active Directory, которая обеспечивает их информацией об учетных записях
пользователей и политике ЦС, а также позволяет публиковать информацию
о выпуске и отзыве сертификатов.
Инфраструктура
PKI открытых
ключей не заменяет
существующие механизмы доверия и аутентификации
доменов Windows 2000, в основе которых лежат контроллер домена (DC –
Domain Controller) и центр распределения ключей
Kerberos (KDC – Key Distribution Center).
Инфраструктура открытых ключей взаимодействует с этими службами, в частности,
обеспечивает масштабируемые, распределенную аутентификацию, целостность и защиту
данных.
Рис.
1. Компоненты инфраструктуры открытых ключей операционной системы Microsoft Windows 2000
На
всех рабочих станциях и серверах, которые работают под управлением операционных
систем Windows 2000 и Windows NT, и на всех рабочих станциях,
которые работают под управлением операционных систем Windows 95 и Windows 98
обеспечена поддержка приложений, использующих криптографию с открытыми ключами.
На рис. 2 показана блок-схема служб, формирующих поддержку таких приложений.
Краеугольный камень этих служб – криптографический интерфейс CryptoAPI
2.0. Он обеспечивает стандартный доступ к функциям криптографических модулей
CSP (Cryptographic Service Provider). CSP могут быть программными или работающими совместно с аппаратными криптографическими
устройствами. Они способны поддерживать разнообразные криптографические
алгоритмы и степени защиты ключей. Выше уровня криптографических
служб находится набор служб управления сертификатами. Они поддерживают сертификаты,
соответствующие стандарту X.509 версии 3.
Имеются также службы для обработки криптографических сообщений, поступающих
в стандартных форматах. Эти службы поддерживают форматы PKCS, используемые
для криптографии с открытыми ключами, развивающуюся инфраструктуру
открытых ключей, определяемую рекомендациями IETF и использующую сертификаты
X.509 (PKIX).
Другие
службы используют интерфейс CryptoAPI с целью обеспечения дополнительных возможностей
разработчикам приложений. Защищенный канал (Schannel) поддерживает аутентификацию
и шифрование передаваемых по сети данных с помощью протоколов TLS (Transport
Layer Security) и SSL (Secure Sockets Layer), ставших отраслевыми стандартами.
Доступ к этим функциям осуществляется через интерфейс WinInet для протокола
HTTP (HTTPS) и через интерфейс SSPI для других протоколов. Технология Authenticode
реализует механизмы создания электронной цифрой подпись компонентов и ее проверку. Она используется в основном
для определения источника и целостности, загружаемых через Интернет компонентов,
но может быть использована и в других целях. Поддерживаются также универсальные
интерфейсы для смарт-карт. Они используются для интегрирования смарт-карт независимо
от конкретных приложений и служат основой для системы регистрации в домене с
помощью смарт-карт.
Рис.
2. Службы поддержки приложений, использующих инфраструктуру открытых ключей
Включенные
в операционную систему Windows 2000 службы сертификации
предоставляют предприятию средства для организации центров сертификации.
Службы сертификации содержат применяемый по умолчанию, модуль политики, который
можно использовать для выдачи сертификатов пользователям, компьютерам и службам.
При этом выполняется идентификация объекта, отправившего запрос на сертификат,
и проверка допустимости запрошенного сертификата в соответствии с политикой
безопасности домена. Разработчики могут изменить этот модуль таким образом,
чтобы он соответствовал другой политике, а также расширить поддержку ЦС для
различных сценариев Интранета и Интернета.
В
рамках инфраструктуры открытых ключей можно поддерживать как ЦС предприятия,
так и внешние ЦС, связанные с другими организациями и коммерческими
поставщиками услуг. Эта возможность позволяет предприятию подстраивать
свою среду под конкретные условия деятельности.
Инфраструктура
открытых ключей предполагает иерархическую модель построения центров сертификации.
Такая модель обеспечивает масштабируемость, удобство
администрирования и согласованность с растущим числом коммерческих продуктов
и ЦС различных поставщиков. Простейшая форма иерархии ЦС состоит
из одного ЦС, а в общем случае – из множества ЦС с явно определенными
отношениями родительский-дочерний, как показано на рис. 3. Как видно из
этого рисунка, допускается существование не связанных между собой иерархий.
Другими словами, центры сертификации не обязательно должны иметь общий родительский
(корневой) ЦС на самом верхнем уровне.
В
этой модели дочерние ЦС сертифицируются
родительским ЦС. ЦС, находящийся
на самом верхнем уровне иерархии, обычно называется корневым
(root) ЦС. Подчиненные ЦС являются промежуточными
(intermediate) или выдающими
(issuing) ЦС. В данном документе выдающим
ЦС называется тот центр сертификации, который выдает сертификаты конечным
пользователям. Промежуточным ЦС здесь
называется тот ЦС, который не является корневым и выдает сертификаты только
другим ЦС, а не конечным пользователям.
Рис.
3. Иерархия центров сертификации
Фундаментальное
преимущество этой модели состоит в том, что проверка сертификатов требует доверия
только относительно малому числу корневых ЦС. В то же время эта модель позволяет иметь различное число ЦС, выдающих
сертификаты. Поддержка нескольких выдающих ЦС применяется по ряду причин практического
свойства. К ним относятся следующие:
·
Использование.
Сертификаты могут выдаваться для различных целей (например,
для защиты электронной почты, сетевой аутентификации и так далее). Политика
выдачи сертификатов для этих целей может быть различной, а существование нескольких
ЦС позволяет реализовать различные политики.
·
Структура
подразделений организации.
Политики выдачи сертификатов могут
различаться в зависимости от роли субъекта в организации. Для разделения этих
политик и управления ими можно создать несколько выдающих ЦС.
·
Территориальное
деление. Организации могут иметь
территориально отдаленные подразделения. Из-за условий сетевой связи между этими
подразделениями может потребоваться несколько выдающих ЦС.
Иерархия
центров сертификации имеет также административные преимущества, в том числе
следующие.
·
Гибкая
настройка среды безопасности ЦС (степень защиты ключа, физическая
защищенность, защита от сетевых атак и так далее) для достижения компромисса
между степенью защиты и удобством применения. Например, для
корневого ЦС можно использовать специализированное криптографическое
оборудование, эксплуатируемое в физически защищенном месте и не подключенное
к сети. Такой ЦС нецелесообразно использовать для выдачи сертификатов конечным
объектам, поскольку это было бы слишком сложно с практической точки зрения.
·
Возможность часто обновлять ключи и сертификаты, выдаваемые выдающими
ЦС, которые находятся в условиях риска компрометации, и при этом не изменять
установленные отношения доверия с корневым ЦС.
·
Возможность отключить часть иерархии ЦС, не затрагивая установленные
отношения доверия. Например, можно закрыть выдающий
ЦС какого-либо отдельно расположенного подразделения и отозвать его сертификаты
без отрицательных последствий для остальной части организации.
В
общем случае желательно, чтобы иерархия ЦС не менялась, но это не является обязательным
условием. Добавление и удаление подчиненных ЦС выполняется
без особых затруднений. Можно также объединить существующие иерархии
ЦС, сделав один из корневых ЦС промежуточным – он будет сертифицироваться
другим корневым ЦС. Перед этим, однако, следует тщательно
рассмотреть вопрос о том, не вызовет ли это противоречие политик и не
нарушит ли ограничение на глубину вложенности,
которое может быть заложено в существующие сертификаты.
Развертывание
служб сертификации Windows 2000 выполняется довольно просто. Перед созданием
ЦС рекомендуется определить домен. Затем создается один или несколько корневых
ЦС. В процессе установки служб сертификации администратор получает пошаговые
инструкции. Далее перечислены основные этапы этого процесса.
·
Выбор сервера для размещения ЦС.
Корневой ЦС может эксплуатироваться на любой платформе Windows 2000 Server,
в том числе с контроллером домена. При выборе сервера следует учесть физическую
защищенность, предполагаемую нагрузку, характеристики связи и другие факторы.
·
Именование.
Имена ЦС указываются в сертификатах, которые они выдают, поэтому не должны изменяться.
Прежде чем выбрать имена центров сертификации, следует рассмотреть такие факторы,
как принятые в организации соглашения по присвоению имен и необходимость различать
ЦС в будущем.
·
Генерация
ключей. Пара ключей центра сертификации –
открытый и секретный – создается при его установке и является уникальной.
·
Сертификат
ЦС. При установке корневого ЦС
автоматически с использованием этой пары ключей генерируется его сертификат,
подписанный им самим. Запрос дочернего ЦС на сертификат может быть направлен
промежуточному или корневому ЦС.
·
Интеграция
с Active Directory. Относящаяся
к ЦС информация записывается в соответствующий объект в Active Directory во
время установки ЦС. Таким образом, клиентам домена предоставляется информация
о доступных ЦС и типах выдаваемых ими сертификатов.
·
Политика
выдачи сертификатов. Модуль политики
автоматически устанавливается и конфигурируется. Уполномоченный администратор
может изменить политику, если это потребуется.
После
создания корневого ЦС устанавливаются промежуточные и выдающие
ЦС, которые подчинены этому корневому ЦС.
Единственная существенная разница в процессе установки таких ЦС заключается
в том, куда направляется запрос на сертификацию –
корневому или промежуточному ЦС. Запрос может направляться автоматически
подключенным к сети ЦС, расположение которых определяются с помощью Active
Directory, либо вручную без использования сети. В любом случае ЦС может начать
работу только после получения и установки сертификата.
Связь
между центрами сертификации предприятия и моделью междоменного доверия Windows 2000
очевидна, но это не означает, что существует прямое соответствие между доверительными
отношениями центров сертификации и доверительными
отношениями доменов. Ничто не мешает одному ЦС обслуживать субъекты из
нескольких доменов, и даже субъекты, находящиеся за пределами доменов. Справедливо
и обратное – один домен может иметь несколько ЦС предприятия.
Центры
сертификации – важные ресурсы, поэтому в большинстве случаев они должны
быть хорошо защищены. Следует рассмотреть следующие меры защиты.
·
Физическая
защита. Поскольку ЦС предприятия
относятся к объектам, пользующимся высокой степенью доверия, они должны быть
защищены от несанкционированных действий.
Это требование определяется значимостью процесса сертификации, выполняемой
данным ЦС. Риск несанкционированных действий значительно уменьшится, если сервер ЦС физически изолировать
в помещении, в которое могут входить только администраторы системы безопасности.
·
Управление
ключами. Ключи ЦС – самая
ценная его часть, поскольку при сертификации основным объектом доверия является
личный ключ ЦС. Сертифицированные криптографические
модули обеспечивают надежное хранение ключей и изолируют криптографические операции с ключами от прочего
программного обеспечения сервера. Это значительно сокращает риск компрометации
ключа ЦС.
·
Восстановление.
Потеря ЦС из-за сбоя оборудования или по иной причине может создать множество
помех в работе и администрировании, сделает невозможным отзыв существующих сертификатов.
Система резервного копирования Windows 2000 обеспечивает архивацию и восстановление
данных центра сертификации.
Как
видно из вышеизложенного, в инфраструктуре открытых ключей Windows 2000
предусмотрены доверительные отношения между несколькими иерархиями ЦС. Эти отношения
могут включать не только иерархии ЦС одного предприятия, но и иерархии ЦС нескольких предприятий, а также коммерческие
ЦС (VeriSign, Thawte и другие ЦС).
В
инфраструктуре открытого ключа имеется возможность административными средствами
установить доверительные отношения между ЦС на основе объектов политики доменов
Windows 2000. Каждому доверенному корневому ЦС система предоставляет
средства для ограничения использования сертификатов, выданных этим ЦС.
Например, можно задать проверку только тех сертификатов, которые выданы ЦС для
проверки подлинности серверов, даже если этот ЦС выдает сертификаты и для других
целей.
Кроме
того, отдельные пользователи могут добавлять доверительные отношения с ЦС, которые
применяются только к ним самим. Это выполняется средствами клиента и не требует
вмешательства администратора.
Альтернативой явного включения в объект политики всех доверенных корневых ЦС является использование перекрестных сертификатов (cross certificates). Эти сертификаты обеспечивают средства для создания цепочки доверия от одного доверенного ЦС к нескольким ЦС. Инфраструктура открытых ключей Windows 2000 тоже способна обрабатывать такие сертификаты и использовать их в процессе принятия решений о доверии. Продолжение->
