Какого элемента pki не существует в службе сертификации active directory windows server

Обновлено: 03.07.2024

Работа с корпоративными и автономными центрами сертификации CA Центр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), является ключевым компонентом программного обеспечения

Работа с корпоративными и автономными центрами сертификации CA

Центр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), является ключевым компонентом программного обеспечения инфраструктуры открытых ключей PKI (Public Pey Infrastructure) в среде Windows Server 2003. Центр CA принимает и обрабатывает запросы на получение сертификатов от пользователей PKI, идентифицирует эти запросы и проверяет их правомерность, выдает сертификаты в соответствии с политикой безопасности PKI, обновляет и аннулирует сертификаты, размещает сертификаты на различных узлах хранения, создает и публикует списки аннулированных сертификатов CRL (Сertificate Revocation Lists), а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL. Центр сертификации Windows 2003 CA может выполнять в безопасном режиме архивирование и восстановление секретных ключей. Чтобы оценить степень развития возможностей центров CA и PKI в среде Windows 2003, в этой статье мы рассмотрим компоненты архитектуры последней реализации служб Certificate Services, а также различия в процедурах развертывания корпоративного и автономного центра CA в среде Windows 2003.

Архитектура Windows 2003 Certificate Services. Архитектура Windows 2003 Certificate Services почти идентична той, которая использовалась Microsoft при реализации предыдущих версий названных служб. Основное различие состоит в том, что здесь Microsoft изменила структуру базы данных CA для реализации поддержки процедур архивирования и восстановления секретных ключей пользователей. Схема данной архитектуры показана на рисунке. Она включает в себя различные модули, базы данных, инструментальные средства администрирования, посредников и прикладной интерфейс CryptoAPI.

Модуль политики реализует правила политики центра CA в соответствии с установками, заданными администратором CA. Данный модуль передает исполнительному механизму CA информацию о структуре сертификата и принимает решение о выдаче сертификата, об отказе в его выдаче или о переводе запроса сертификата в режим ожидания. Для обновления информации о структуре сертификата модуль политики может обращаться к информации, хранящейся в каком-либо каталоге (например, Active Directory) либо в базе данных. Модуль политики, имеющийся в Windows 2003, называется certpdef.dll. Он поддерживает два типа политики: режим корпоративной политики и режим автономной политики. Эти режимы будут подробно рассмотрены ниже. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, следует запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Policy Module, показанной на экране 1.

Модули политики и выходные модули являются настраиваемыми и заменяемыми компонентами, поэтому любая организация может разработать на языках C++ или Visual Basic (VB) собственные модули и интегрировать их в архитектуру Certificate Services. Вся необходимая информация о процессах создания и замещения модулей имеется в комплекте документации Software Development Kit (SDK) для платформы Windows 2003.

Настройка модулей политики и выходных модулей осуществляется с помощью оснастки Certification Authority или через утилиту командной строки certutil.exe. Используя окно свойств объекта CA оснастки Certification Authority, можно добавлять выходные модули, настраивать расширения X.509 для сертификатов (например, определять узлы CDP (CRL Distribution Points) и узлы AIA (Authority Information Access)), а также настраивать параметры публикации для полных списков CRL и списков изменений CRL.

Базы данных. Центр CA имеет собственную базу данных, которая называется CAname.edb. В этой базе хранится информация по транзакциям, связанным с сертификатами, и собственно сертификаты. Здесь же хранятся архивированные секретные ключи. По умолчанию эта база данных хранится в каталоге %systemroot%system32certlog. Исполнительный механизм центра CA взаимодействует с базой данных с помощью файла certdb.dll. С появлением службы Windows 2000 Certificate Services изменилась используемая Microsoft технология работы с базами данных. Теперь здесь используется процессор баз данных Jet, что позволило сделать архитектуру Windows 2000 CA масштабируемой. Отметим, что аналогичная технология используется в базах данных AD и Microsoft Exchange Server.

Средства администрирования. В большинстве случаев для администрирования центра сертификации Windows 2003 CA используется оснастка Certification Authority, но это можно делать и с помощью утилиты командной строки certutil.exe. Оба средства взаимодействуют с исполнительным механизмом центра CA через библиотеку certadm.dll.

Прикладной интерфейс CryptoAPI. Для реализации всех криптографических функций, включая доступ и использование секретных ключей CA, центр сертификации задействует вызовы интерфейса CryptoAPI. Центр CA может хранить свой секретный ключ на жестком диске или на специальном аппаратном устройстве (например, на аппаратном модуле безопасности Hardware Security Module, HSM).

Установка Windows 2003 Certificate Services

При выполнении установки Windows 2003 Certificate Services может быть развернут корневой CA, подчиненный CA, корпоративный CA (интегрированный в AD) или автономный CA (не интегрированный в AD). Если служба Certificate Services устанавливается в корпоративном режиме, то в этом случае активируется аналогичный режим и для модуля политики центра Windows 2003 CA. Рассмотрим, чем отличаются корпоративный и автономный режимы. В таблице приведены сравнительные характеристики параметров, установленных по умолчанию, для автономного и корпоративного центров Windows 2003 CA.

При установке корпоративного центра CA та учетная запись, от имени которой выполняется установка, должна иметь привилегии Enterprise administrator и Domain administrator в корневом домене леса AD. Кроме того, сервер, на который устанавливается корпоративный CA, должен являться членом домена с функционирующей в нем службой AD. Если эти условия не выполнены, в CA installation Wizard будут недоступны возможности перехода в режим установки enterprise CA, соответственно развернуть центр CA можно будет только в автономном режиме.

Для того чтобы установить автономный центр CA, использовать AD необязательно. CA может устанавливаться как на автономный сервер, так и на сервер, входящий в домен, или на контроллер домена (DC). При такой установке не требуются и полномочия Enterprise administrator и Domain administrator, вполне достаточно прав локального администратора на данном сервере. Если при установке автономного центра CA все-таки использовать привилегии Enterprise administrator, в этом случае данный центр будет обладать некоторой дополнительной функциональностью. В частности, если пользователь с правами Enterprise administrator устанавливает автономный центр CA на сервер, входящий в состав домена, то в этом случае центр CA сможет публиковать выпущенные им сертификаты в AD.

Шаблоны сертификатов

Корпоративный центр CA использует шаблоны сертификатов, которые хранятся в структуре AD в контексте имен конфигурации. Шаблон определяет содержание и характеристики сертификата. Кроме того, с помощью шаблонов можно контролировать типы выпускаемых центром CA сертификатов и определять, какие пользователи могут запрашивать сертификаты у корпоративного центра CA, а также сертификаты какого типа могут им выдаваться. В инфраструктуре PKI среды Windows 2003 поддерживаются шаблоны сертификатов версии 2, которые, в отличие от шаблонов версии 1, являются полностью настраиваемыми. Настройка шаблонов осуществляется с помощью оснастки Certificate Templates консоли MMC.

Автономный центр CA не может использовать шаблоны сертификатов AD, в этом случае нельзя выполнять контроль типов сертификатов и пользователей, их получающих. По умолчанию автономный CA может выдавать только сертификаты, предназначенные для Web-аутентификации (Secure Sockets Layer, SSL; или Transport Layer Security, TLS), защиты электронной почты (Secure MIME, S/MIME), аутентификации сервера, цифровой подписи и для работы с протоколом IP Security (IPSec). Тем не менее можно модифицировать Web-интерфейс автономного центра CA (например, для того чтобы в списке отображались другие типы сертификатов) или запрашивать другие типы сертификатов, используя для этого значения специальных идентификаторов объектов (OID), которые хранятся в X.509-расширении сертификата Extended Key Usage.

Получение дополнительной информации при запросе сертификата

В процессе регистрации сертификата корпоративный центр CA ищет в структуре Active Directory информацию о пользователе, которая потребуется центру для заполнения определенных полей сертификата. Например, в поле X.509 SubjectAltName сертификата, выданного корпоративным центром CA, содержится ссылка на имя пользователя, определяющее его в AD, — User Principal Name (UPN). Если центр CA является автономным, он не имеет доступа к AD, поэтому информация, идентифицирующая пользователя и необходимая для получения сертификата с Web-сайта регистрации, должна вводиться пользователем вручную.

Как в корпоративных, так и в автономных центрах CA можно изменять установленные по умолчанию параметры, добавляемые центром CA к запросу сертификата. Это делается в процессе регистрации сертификатов путем редактирования файла certdat.inc, который находится в каталоге %systemroot%system32certsrv. Допускается изменение значений, установленных по умолчанию, для следующих параметров сертификата: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, и sDefaultCountry. Если привести значения этих параметров в соответствие с используемыми в организации наименованиями, можно будет сократить объем вводимой пользователем информации при запросе сертификата.

Автоматическая регистрация сертификатов

Централизованное архивирование ключей

Корпоративный центр CA поддерживает механизмы централизованного архивирования ключей в базе данных CA, а автономный центр — нет. Возможности технологии архивирования и восстановления ключей CA более подробно обсуждаются в статье «Автоматическое архивирование и восстановление ключей в инфраструктуре Windows Server 2003 PKI», опубликованной в № 3 журнала Windows IT Pro/RE за 2006 г.

Утверждение запроса сертификата

В корпоративных центрах CA имеется поддержка механизмов автоматического и ручного утверждения запросов сертификатов. Для того чтобы настроить свойства режима обработки запросов сертификатов, можно воспользоваться либо свойствами корпоративного CA (через свойства модуля политики), либо свойствами шаблона сертификата версии 2 (с помощью вкладки Issuance Requirements окна свойств шаблона сертификата). Если настройка режима обработки запросов выполняется через свойства шаблона сертификата версии 2, то следует иметь в виду, что внесенные при этом изменения будут применены только к сертификатам того типа, который определяется данным шаблоном. Можно задать настройку, обязывающую администратора утверждать все поступающие запросы сертификатов вручную, независимо от установок в шаблоне сертификата. Для этого при настройке режима обработки запросов в свойствах CA нужно выбрать пункт Set the certificate request status to pending. The administrator must explicitly issue the certificate. Эти же пункты доступны и для автономного центра CA, с той лишь разницей, что автономный CA не может использовать шаблоны сертификатов, и, следовательно, не удастся настроить свойства обработки запросов для отдельного шаблона сертификата. В отличие от корпоративного центра, автономный CA при аутентификации поступающих запросов не использует внутренние механизмы аутентификации Windows, соответственно компания Microsoft не рекомендует устанавливать режим автоматического утверждения в свойствах обработки запросов для автономных центров CA. В этих случаях всегда следует оставлять установку, сделанную по умолчанию, в соответствии с которой каждый поступающий запрос сертификата должен утверждаться администратором вручную.

Опубликование сертификатов и списков CRL

Корпоративные центры CA хранят и публикуют сертификаты, а также полные списки CRL и списки изменений CRL в Active Directory. В то же время как корпоративные центры, так и автономные CA могут осуществлять размещение данных в файловой системе. Каждый размещенный в AD сертификат автоматически отображается на учетную запись того, кто его запрашивал. Служба Active Directory добавляет сертификат к многозначному атрибуту UserCertificate пользователя или объекта AD inetOrgPerson. Отметим, что не каждый выданный корпоративным центром CA сертификат автоматически публикуется в AD. Примерами сертификатов, которые не будут публиковаться автоматически, могут служить сертификат агента регистрации или сертификат для подписи списка CTL (certificate trust list).

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

Выбор типа CA, оптимального для решаемых задач

Итак, мы определили различия между корпоративным и автономным центром CA и теперь, на основании полученных знаний, можем выбирать конфигурацию центра CA, оптимальную для конкретной ситуации. Развертывание корпоративного центра Windows 2003 CA будет наилучшим решением для работы с сертификатами пользователей, имеющих учетные записи в AD и использующих протокол Kerberos для их аутентификации в инфраструктуре AD. Для внешних пользователей (например, пользователей из внешней сети, не имеющих учетных записей в инфраструктуре Windows внутренней сет) оптимальным решением будет использование автономного центра Windows 2003 СA.

Работают в Windows еще с версии 2000. ADCS позволяют выдавать и обслуживать цифровые сертификаты на основе ключей.

Любой сертификат представляет собой пару закрытого и открытого ключа. Закрытый ключ – приватная информация, идентифицирующая владельца, требующая защиты и не подлежащая распространению. Открытый ключ – доступная любому часть, использующаяся для проверки

На практике сертификаты применяются для:

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

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

За 17 лет службы сертификации конечно же модернизировались. Последние серьезные изменения в ADCS были внесены в версиях Windows 2012 и 2012 R2 . Наиболее важные из них:

Поддержка модуля политики для службы регистрации сертификатов для сетевых устройств
Аттестация ключей доверенного платформенного модуля (TPM)
Windows PowerShell для служб сертификатов
Поддержка обновления сертификата с прежним ключом
Поддержка международных имен доменов

Простейшая архитектура Certificate services состоит из 2х серверов: корневого и выдающего. Помимо этого в инфраструктуре наверняка присутствует домен-контроллер, который может быть использован, как точка распространения сертификатов. Также для этих целей желательно иметь сервер с ролью Web. В прочем этот функционал может быть настроен на сервере с ролью выдающего центра сертификации.

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

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

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

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

включить корневой центр сертификации
обновить CRL
опубликовать полученный CRL на всех точках проверки отозванных сертификатов.

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

Все операции по управлению сервисом выполняются из нескольких консолей:

А также с помощью PowerShell и утилиты certutil, с возможностями которой можно ознакомится, набрав certutil /help в командной строке Windows.

В частности с помощью командной строки можно публиковать сертификаты и списки отозванных сертификатов в базе Active Directory. Также через службы Active Directory Domain Services (а именно через групповые политики) можно настроить распространение сертификатов: например, добавление сертификата корневого центра сертификации в Trusted certificates рабочих станций организации.

Помимо того, что сертификат содержит пару закрытого и открытого ключа, в нем также хранится служебная информация, в том числе о том, кому и когда выдан сертификат, алгоритмах генерации длине ключа и пр. Сертификат генерируется по шаблону, который должен быть опубликован уполномоченным администратором. По умолчанию Active Directory Certificate Services имеют набор заготовок шаблонов для различных сервисов (Web-server, Exchange server, RDP Gateway server и пр ), на базе которых можно также создавать шаблоны под собственные нужды.

Как видно из скриншота сертификаты широко применяются для защиты информации и информационных каналов. Наиболее часто используются:

Сертификаты для веб ресурса.
Сертификаты для защиты соединения.
Сертификаты для цифровой подписи.

Вы можете использовать публичную инфраструктуру ключей (PKI) для обеспечения безопасности доступа к вашему порталу с применением встроенной аутентификации Windows (Integrated Windows Authentication) для аутентификации пользователей.

Для использования интегрированной аутентификации Windows (IWA) и PKI необходим ArcGIS Web Adaptor (IIS) , развернутый на веб-сервере Microsoft IIS . Вы не можете использовать ArcGIS Web Adaptor (Java Platform) для выполнения встроенной аутентификации Windows. Если этого еще не сделано, установите и настройте ArcGIS Web Adaptor (IIS) для работы с порталом.

Примечание:

Если вы собираетесь добавить на ваш портал сайт ArcGIS Server и хотите использовать на сервере Windows Active Directory и PKI, вам потребуется отключить аутентификацию с использованием сертификата клиента на основе PKI на вашем сайте ArcGIS Server и разрешить анонимный доступ перед добавлением его на портал. Хотя это может показаться нелогичным, но это необходимо, чтобы сайт был свободен для интеграции с порталом и мог считать пользователей и роли из портала. Если на сайте ArcGIS Server не используется аутентификация с помощью клиентского сертификата на основе PKI, никаких действий выполнять не требуется. Подробные инструкции по добавлению сервера к вашему порталу см. в разделе Интеграция сайта ArcGIS Server с порталом.

Настройте свой портал на использование Windows Active Directory

Сначала настройте портал для использования SSL для всех коммуникаций. Затем обновите хранилище аутентификаций вашего портала, чтобы использовались учетные записи и группы Windows Active Directory.

Обновление хранилища аутентификаций портала

Затем обновите хранилище аутентификаций вашего портала, чтобы использовались учетные записи и группы Windows Active Directory.

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

В тех редких случаях, когда Windows Active Directory чувствительна к регистру, установите для параметра caseSensitive значение "true" .

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

Добавление пользователей из корпоративной системы на портал

По умолчанию корпоративные пользователи могут работать с веб-сайтом портала. Однако они могут лишь просматривать элементы, открытые для всех пользователей организации. Это связано с тем, что корпоративные учетные записи не были добавлены на портал, и им не были выданы права доступа.

Добавьте учетные записи на портал одним из следующих методов:

(однократно, в пакетном режиме с использованием файла CSV или из существующих корпоративных групп)

Рекомендуется назначить хотя бы одну корпоративную учетную запись в качестве Администратора портала. Это можно сделать, выбрав роль Администратор при добавлении учетной записи. Теперь, когда у вас появилась дополнительная учетная запись администратора портала, вы можете назначить учетной записи главного администратора роль Пользователя или удалить ее. Более подробно см. в разделе О учетной записи главного администратора.

После того как вы добавите учетные записи и выполните перечисленные ниже шаги, пользователи смогут входить в организацию и работать с ее ресурсами.

Установите и включите аутентификацию Active Directory Client Certificate Mapping

Active Directory Client Certificate Mapping недоступна в установке IIS по умолчанию. Вам необходимо установить и включить эту возможность.

Установите аутентификацию Client Certificate Mapping

Инструкции по ее установке отличаются в зависимости от вашей операционной системы.

Установка с Windows Server 2016

Выполните следующие шаги, чтобы установить аутентификацию Client Certificate Mapping с Windows Server 2016:

Откройте инструменты Администрирование и щелкните Server Manager .
На панели отображения иерархии Server Manager раскройте Роли и щелкните Веб-сервер (IIS) .
Разверните роли Web Server и Безопасность .
В разделе роли Безопасность выберите аутентификацию Client Certificate Mapping Authentication и нажмите Далее .
Нажимайте Далее , пока не появится вкладка Выбор объектов (Select Features) и щелкните Установить .

Установка с Windows Server 2008/R2 и 2012/R2

Выполните следующие шаги, чтобы установить аутентификацию Client Certificate Mapping с Windows Server 2008/R2 и 2012/R2:

Откройте инструменты Администрирование и щелкните Server Manager .
На панели отображения иерархии Server Manager раскройте Роли и щелкните Веб-сервер (IIS) .
Перейдите к разделу Сервисы ролей и щелкните Добавить сервисы ролей .
На странице Выбрать сервисы ролей Мастера добавления сервисов ролей выберите Client Certificate Mapping Authentication и щелкните Далее .
Нажмите Установить .

Установка с Windows 7, 8 и 8.1

Выполните следующие шаги, чтобы установить аутентификацию Client Certificate Mapping с Windows 7, 8 и 8.1:

Откройте Панель управления и щелкните Программы и компоненты > Включение или отключение компонентов Windows .
Раскройте Информационные сервисы Интернета > World Wide Web Services > Безопасность и выберите Client Certificate Mapping Authentication .
Нажмите OK .

Включите аутентификацию Active Directory Client Certificate Mapping

После установки Active Directory Client Certificate Mapping включите объект, выполнив описанные ниже действия.

Запустите Internet Information Server (IIS) Manager.
В узле Подключения щелкните имя вашего веб-сервера.
Дважды щелкните Авторизация в окне Просмотр возможностей .
Убедитесь, что отображается Аутентификация Active Directory Client Certificate Mapping . Если компонент не отображается или недоступен, то перезагрузите веб-сервер, чтобы завершить установку компонента Аутентификация Active Directory Client Certificate.
Щелкните дважды Active Directory Client Certificate Authentication и выберите Включить в окне Действия .

Настройка ArcGIS Web Adaptor для работы с аутентификацией SSL и сертификатами клиентов

Выполните следующие шаги для настройки ArcGIS Web Adaptor для работы с аутентификацией SSL и сертификатами клиентов:

Запустите Internet Information Services (IIS) Manager.
Раскройте узел Подключения и выберите ваш сайт ArcGIS Web Adaptor .
Дважды щелкните Авторизация в окне Просмотр возможностей .
Отключите все формы аутентификации.
Снова выберите ваш ArcGIS Web Adaptor в списке Подключения .
Дважды щелкните Настройки SSL .
Включите опцию Требовать SSL и выберите опцию Требовать под Сертификаты клиентов .
Нажмите Применить , чтобы сохранить изменения.

Убедитесь, что вы можете зайти на портал с помощью Windows Active Directory и PKI

Выполните следующие шаги, чтобы убедиться, что вы можете зайти на портал с помощью Windows Active Directory и PKI:

Запрет создания собственных учетных записей пользователями

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

В окне для указания имени ЦС введите значения всех полей и нажмите Далее.

Введенные здесь данные носят информативный характер. Рекомендуется их внести. Аббревиатуры несут следующий смысл: "O" — Organization, "OU" — Organization Unit, "L" — City (Location), "S" — State or province, "C" — Country/region, "E" — E-mail.

Введите период действия сертификата для создаваемого ЦС.

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

Для добавления шаблонов сертификатов:

Выберите следующие настройки:

Значение параметра Минимальный размер ключа должно быть не менее 1024.

Для выписки сертификатов пользователю Administrator и обычным пользователям с помощью mmc-консоли:

Закройте окно Консоль1. Для сохранения консоли нажмите Да.

Рекомендуется сохранить данную консоль для удобства использования в дальнейшем. Причем если работать в системе с правами учетной записи User, то в консоли Сертификаты - текущий пользователь будут отображаться сертификаты пользователя User. Любой пользователь домена на локальном компьютере из консоли Сертификаты - текущий пользователь может запросить сертификат.

На этом настройка Центра Сертификации и выдача сертификатов пользователям завершена.

Читайте также: