Установка Certification Authority

Содержание

Разворачивание цепочки центров сертификации на основе microsoft ca | для системного администратора
Mac os x
Pki tasks
Planning ca hierarchy
Planning cdp/aia extensions
Planning validity periods
Prologue
Windows
В ubuntu
Настройка web-службы регистрации сертификатов
Настройка групповой политики для выдачи rdp сертификатов
Настройка службы сертификатов active directory
Подписываем rdp файл и добавляем отпечаток доверенного rdp сертификата
Предупреждение о самоподписанном сертификате rdp
Программа сервера на go
Создаем наше ca
Создаем сертификат подписаный нашим са
Создаем шаблон rdp сертификата в центре сертификации (ca)
Установка certification authority
Установка и настройка удостоверяющего центра
Установка и настройка удостоверяющего центра. создание са сертификата
Установка службы сертификации active directory
Conclusion

Разворачивание цепочки центров сертификации на основе microsoft ca | для системного администратора

В данной статье деться пошаговая инструкция по установке и настройке центров сертификации (Certification authority) на основе служб сертификатов (Certificate services) Microsoft входящей в Windows 2003.

Схема, которую будем реализовывать:

Корневой центр сертификации будем устанавливать на компьютер с именем RootCA.

Для развёртывания корневого центра сертификации необходим компьютер под управлением ОС Windows Server с установленным IIS версии 6.0 или выше. Необходимо проверить наличие ASP на сервере IIS. Компьютер не должен входить в домен. Подключать данный компьютер к сети так же не обязательно, однако, сетевая карта на компьютере должна присутствовать.

Установка центра сертификации проходит по умолчанию. То есть во время установки никакие настройки менять не надо. Убеждаемся, что выбрана установка Stand-alone root CA

Единственная вещь, которую необходимо указать – это имя нашего корневого центра сертификации (назовём его ROOT CA).

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

Заходим с свойства корневого центра сертификации.
Переходим на вкладку Extensions
На этой вкладке в выпадающем списке выбираем значение CRL Distribution Point.
Затем в поле ниже удаляем две записи начинающиеся на http:// и file://
Далее в этом же поле добавляем две записи вида:
Затем на вкладке в выпадающем списке выбираем значение Authority Information Access.
В поле ниже удаляем две записи начинающиеся на http:// и file://
Далее в этом же поле добавляем две записи вида:

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

Затем в появившемся окне меняем значение CRL Publication Interval на необходимое, например, на 1 год. (Это означает, что список отозванных сертификатов, будет действителен в течении года).

После этих действий, список отозванных сертификатов может перестать публиковаться в виде файла (наверное, это фича, а не бага), и его придётся экспортировать из реестра (как это сделать будет описано ниже).

После всех действий рекомендуется перегрузить центр сертификации.

На этом настройка корневого центра сертификации закончена. Но он нам ещё понадобиться для выписки сертификата.

Теперь займёмся установкой подчинённого центра сертификации. Для развёртывания подчинённого центра сертификации необходим компьютер под управлением ОС Windows Server 2003 Enterprise с установленным IIS версии 6.0 или выше. Необходимо проверить наличие ASP на сервере IIS. Компьютер должен быть членом домена (может быть контроллером домена).

При установке центра сертификации необходимо указать, что наш сервер является Enterprise Subordinate CA

И задать ему имя (например, SUB CA).

После установки, подчинённый центр сертификации попросит указать корневой центр сертификации или сохранить запрос на сертификат в файл. Так как корневой центр сертификации не доступен по сети, то мы сохраняем запрос в файл.

Затем переносим этот файл запроса на корневой центр (ROOT CA) сертификации, импортируем запрос в центр сертификации:

и затем, на основе импортированного запроса выдаём сертификат:

Затем данный сертификат экспортируется в файл.

Далее публикуем список отозванных сертификатов (даже если у нас нет отозванных сертификатов, данную операцию всё равно необходимо выполнить).

Затем нам необходимо 3 файла перенести с машины, где установлен корневой центр сертификации на машину с подчинённым центром сертификации:

Файл, содержащий открытый ключ корневого центра сертификации, в нашем случае RootCA_ROOT CA.cer находиться в папке %system root%system32certsrvcertenroll – это должен быть единственный файл сертификата, в имени которого содержится имя компьютера и имя центра сертификации.
Файл, содержащий сертификат, выданный подчинённому центру сертификации на основании запроса. В нашем случае это SubCA.domian.local_SUB CA.cer. Местоположение данного файла указывается при экспортировании данного сертификата в файл (как было описано выше).
И последний файл, это файл, содержащий список отозванных сертификатов. Этот файл находиться в папке %system root%system32certsrvcertenroll и имеет расширение .crl. В нашем случае это ROOT CA.crl (файл содержащий в конце имени файла знак « », содержит дельту списка отозванных сертификатов). Однако, как было описано выше, файла, содержащего список отозванных сертификатов, может не быть в этой папке, тогда этот файл необходимо экспортировать из реестра. Для этого открываем консоль управления сертификатами локального компьютера, и экспортируем необходимый список отозванных сертификатов в файл:

Как было сказано выше, эти три файла мы переносим с корневого центра сертификации на подчинённый. Сертификат корневого центра сертификации импортируем на компьютер с установленным подчинённым центром сертификации (для этого достаточно просто открыть файл сертификата и нажать кнопку «установить сертификат»). Файл, содержащий список отозванных сертификатов необходимо положить в папку %system root%system32certsrvcertenroll (это тот путь, который мы указывали, когда меняли свойства корневого центра сертификации). А так же необходимо импортировать в реестр, с помощью остнастки – сертификаты. Файл, содержащий сертификат подчинённого центра сертификации необходимо импортировать в подчинённый центр сертификации:

Теперь запускаем подчинённый центр сертификации.

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

Теперь необходимо настроить подчинённый центр сертификации.

В список доступных к выдачи шаблонов сертификатов необходимо добавить два шаблона Enrollment Agent (Computer) и Enrollment Agent, для этого нажимаем правой кнопкой мыши на Certificate Templates, из контекстного меню выбираем New и затем Certificate Template to Issue.

Про сертификаты: Защищённые браузеры: выбираем лучший

В появившемся окне выбираем два шаблона сертификатов Enrollment Agent и Enrollment Agent (Computer) и нажимаем «Ok».

И убеждаемся, что эти шаблоны сертификатов появились в списке доступных к выдачи шаблонов сертификатов:

Далее, для сотрудника, отвечающего за выдачу сертификатов, необходимо выписать сертификат Enrollment Agent. Это можно сделать через Web-интерфейс. Для этого идём на адрес http://имя_компьютера_подчинённого_ЦС/certsrv (в нашем случае http://SubCA/certsrv). На странице выбираем пункт: Request a certificate:

Далее выбираем Advanced certificate request:

Затем Create and submit a request to this CA:

Затем из выпадающего списка выбираем шаблон Enrollment Agent и нажимаем Submit. После этого устанавливаем полученный сертификат на компьютер.

Для того, чтобы выписывать сертификаты другим пользователям необходимо или иметь сертификат Enrollment Agent установленный в профиле пользователя, который будет выдавать сертификаты, или Enrollment Agent (Computer), установленный на компьютере, на котором будет осуществляться выдача сертификатов.

Для того, чтобы запросить сертификат Enrollment Agent или Enrollment Agent (Computer) необходимо входить в группу Администраторов Домена.

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

Для проверки возможности авторизации в домене на основе сертификата необходимо проверить, что с компьютера, с которого осуществляется вход, доступна сетевая папка \имя_сервера_подчинённого_ЦСcertenroll (в нашем случае \SubCAcertenroll) и все файлы, имеющие расширение .crl доступны для чтения.
Оригинал тут

Mac os x

Safari, FireFox, Chrome — используют системный репозиторий.

Запускаем KeyChain Access.Идём в меню File — Import Items (login или System) — выбираем файл rootCA.crt.Когда нас спросят, отвечаем — Always Trust.

Для вашего личного Safari достаточно выбрать login.

Pki tasks

Во-первых, нужно определиться с задачами, которые могут потребовать внедрения PKI:

Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN;
Внедрение защищённых сетевых протоколов — L2TP, SSL, IPsec;
Внедрение защищённой почты с шифрованием и/или подписью писем;
Внедрение цифровых подписей документов и файлов, что гарантирует их целостность и альтернативу ручной подписи.
Внедрение защищённых файловых хранилищ с шифрованием особо конфиденциальной информации.

Если из всего вышеперечисленного вам не нужно, PKI вам не нужна так же.

Planning ca hierarchy

В одном из своих предыдущих постов я вёл дискуссию об иерархиях PKI: Обсуждение схем иерархии Certification Authority. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии. Двухуровневая иерархия выглядит крайне привлекательно:

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

Создание 3-х уровневой иерархии уже будет подразумевать разделение иерерхии на области действий CPS (Certificate Practice Statement) и будут подвержены различным политикам управления серверами CA. Это достаточно долгая песня и о ней говорить не будем.

Planning cdp/aia extensions

Об этом у меня написано уже достаточно много:

Planning validity periods

На какой срок будем выдавать сертификаты для каждого типа CA? 20 лет мне кажется слишком круто, ведь через 20 лет в вашей компании может всё круто поменяться и если ваш бизнес не завязан на предоставлении услуг цифровых сертификатов, 20 лет, наверное, слишком большой срок.

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

Prologue

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается.

К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> ????? –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI.

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

При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI (Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC.

Windows

IE, Chrome — используют репозиторий сертификатов Windows.

Мой путь к нему таков:

Chrome — Settings — Manage Certificates…Выбрать таб Trusted Root Certificate Authorities — Import — rootCA.crtперезапустить Chrome

FireFox на виндоус имеет свой репозиторий.

Java имеет свой репозиторий.

В ubuntu

sudo mkdir /usr/share/ca-certificates/extra
sudo cp rootCA.crt /usr/share/ca-certificates/extra/rootCA.crt
sudo dpkg-reconfigure ca-certificates
sudo update-ca-certificates

Настройка web-службы регистрации сертификатов

В окне указать центр сертификации для веб-службы регистрации сертификатов выбираем пункт «Имя ЦС».

Тип проверки подлинности – имя пользователя и пароль.

Учетная запись службы CES – использовать встроенное удостоверение пула приложений.

В окне выбора сертификата проверки подлинности сервера выберите существующий сертификат, затем нажмите кнопку настроить.

Настройка выполнена.

Настройка групповой политики для выдачи rdp сертификатов

Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.

Настройка службы сертификатов active directory

Заходим в настройки.

Выбираем службу центр сертификации.

Вариант установки – центр сертификации предприятия.

Тип центра сертификации – корневой. Это необходимо для того, что бы в дальнейшем мы могли самостоятельно выдавать и подписывать сертификаты.

В следующем окне нужно выбрать пункт создать новый закрытый ключ.

Затем необходимо указать параметры шифрования. Вы можете указать свои параметры, или параметры как у меня на рисунке ниже.

Про сертификаты: ViPNet Coordinator HW | Сетевые экраны, Виртуальные частные сети, Шифрование | ИнфоТеКС

В следующем окне указывается имя центра шифрования.

Затем указывается срок действия центра сертификации. По умолчанию он равен 5 годам. Так и оставим.

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

Подтверждаем настройку.

Перейдем к настройке web-службы регистрации сертификатов.

Подписываем rdp файл и добавляем отпечаток доверенного rdp сертификата

Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

Get-WmiObject -Class “Win32_TSGeneralSetting” -Namespace rootcimv2terminalservices|select|select SSLCertificateSHA1Hash

Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:

Предупреждение о самоподписанном сертификате rdp

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

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

Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».

Программа сервера на go

Программа сервера на Go myserver.go, которая использует наш подписаный сертификат.

Создаем наше ca

Первая команда создаёт корневой ключ

openssl genrsa -out rootCA.key 2048

Для меня ключ 2048 bit достаточен, если вам хочется, вы можете использовать ключ 4096 bit.

Вторая команда создаёт корневой сертификат.

openssl req -x509 -new -key rootCA.key -days 10000 -out rootCA.crt

Отвечать на вопросы тут можно как душе угодно.

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

10000 дней срок его годности, примерно столько живет сертификат, которым google требует подписывать андроид приложения для Google Play. Если вы паникер, подписывайте на год или два.

Все! Теперь мы можем создавать сертификаты для наших серверов и устанавливать корневой сертификат на наши клиентские машины.

Создаем сертификат подписаный нашим са

Генерируем ключ.

openssl genrsa -out server101.mycloud.key 2048

Создаем запрос на сертификат.

openssl req -new -key server101.mycloud.key -out server101.mycloud.csr

Тут важно указать имя сервера: домен или IP (например домен

server101.mycloud

Common Name (eg, YOUR name) []: server101.mycloud

и подписать запрос на сертификат нашим корневым сертификатом.

openssl x509 -req -in server101.mycloud.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server101.mycloud.crt -days 5000

Теперь на клиенты нужно установить корневой сертификат rootCA.crt

rootCA.crt — можно давать друзьям, устанавливать, копировать не сервера, выкладывать в публичный доступrootCA.key — следует держать в тайне

Создаем шаблон rdp сертификата в центре сертификации (ca)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
Сделайте копию шаблона сертификата Computer (Certificate Templates -> Manage -> Computer -> Duplicate);
На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
Теперь на вкладке Extensions в политике приложений (Application policy) нужно ограничить область использования такого сертификата только для Remote Desktop Authentication (укажите следующий object identifier — 1.3.6.1.4.1.311.54.1.2). Нажмите Add -> New, создайте новую политику и выберите ее;
В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
Сохраните шаблон сертификата;
Теперь в оснастке Certificate Authority, щёлкните по папке Certificate Templates, выберите New ->Certificate Template to Issue -> выберите созданный шаблон RDPTemplate.

Сегодня рассмотрим как развернуть центр сертификации windows, и поговорим для чего он нужен.
Собственный центр сертификации нужен для создания собственной инфраструктуры PKI – Public Key Infrastructure, то есть инфраструктуры открытых ключей. Если говорить в двух словах, то работает эта система так:

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

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

Клиент и сервер согласовывают алгоритм шифрования, сервер отправляет клиенту свой сертификат, подписанный ЦС, и открытый ключ. Клиент проверят валидность сертификата, имени сервера ,которое вписано в сертификат, и посылает серверу случайный ключ, зашифрованный открытым ключом сервера. Сервер расшифровывает его своим закрытым ключом, и устанавливает соединение используя тот самый случайный ключ.

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

Сертификаты бывают: Самоподписанные (self-signed) – сервер сам выпускает сертификат, он ни кем не удостоверяется, поэтому ему по умолчанию не будут доверять.

Wildcard сертификаты можно выдавать на область имен – например *.domaim.ru будет действовать на все поддомены.

Про сертификаты: Программа лояльности Swatch Club | Swatch® Россия

SAN (Subject Alternative Name) – В такой сертификат можно вписать дополнительные имена серверов, например при публикации OWA, нам потребуется несколько имён,что не делать несколько сертификатов, имена можно вписать в один.

Для установки сервера CA устанавливаем следующие роли:

CA1

Выберем сам центр сертифкации, и веб интерфейс:

CA2

Enterprise – установка центра в существующий домен:

CA3

Сделаем наш сервер корневым:

CA4

Сгенерируем новый приватный ключ:

CA5

Внимание! Я при установке выбрал алгоритм подписи sha1. Данный алгоритм устарел, и браузер хром ругается, при заходе на сайт.

sha1_poor

Поэтому при установке выбирайте минимум sha256. Если же Вы уже установили CA с алгоритмом sha1 поменять его можно через командную строку:

certutil -setreg cacspCNGHashAlgorithm SHA256
net stop certsvc
net start certsvc

CA6

Выбираем имя нашего центра сертификации:

CA7

Тут можно выставить время действия корневого сертификата:

CA8

CA9

Дополнительные сервисы – оставим по умолчанию:

CA10

Теперь нам доступен веб интерфейс, по адресу http://dc1/csertsrv

CA12

По ссылке Download a CA сертификат можно скачать корневой сертификат ЦС.

Теперь на серверах мы сможем генерировать запросы на сертификаты, и подписывать их в нашем свежеустановленном центре сертификации. Для этого нужно сгенерировать запрос на сертификат с расширением req, открыть его блокнотом и скопировать запрос в поле, которое находится в веб интерфейсе, под ссылкой Request a certificat. У центра сертификации есть шаблоны, по которым он сможет выпускать сертификаты под разные задачи.

Если у Вас есть вопросы, задавайте их на форуме, или ниже в комментариях.

Установка и настройка удостоверяющего центра

Запустите консоль управления Microsoft (пуск, выполнить, mmc).

Далее нажмите файл, а затем добавить или удалить оснастку.

В левой части нужно выбрать пункт «Сертификаты» и нажать кнопку добавить.

В появившемся окне выбрать пункт учетной записи компьютера.

В следующем окне ничего не меняем и нажимаем кнопку готово. Оснастка добавлена.

В левой части окна можно увидеть папки, в которых хранятся сертификаты (11 штук). Они сортированы по типам сертификатов. Если нажать на папку «Личное» то можно посмотреть сертификаты в этой папке.

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

Появится окно перед началом работы. Жмем далее.

Видим окно запрос сертификатов и нажимаем «заявка».

Запускается процесс установки сертификата. После успешной установки появиться следующая надпись «Состояние: Успешно».

Теперь нам нужно связать сертификат с веб-сервером. Для этого нужно запустить диспетчер служб IIS.

В левой части окна нажать сайты, default web site, изменить привязки.

В появившемся окне нажмите добавить и введите данные как на изображении ниже.

Сохраните изменения и закройте окно.

Установка и настройка удостоверяющего центра. создание са сертификата

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

На отдельном компьютере установите ОС Windows Server 2008 R2 и СКЗИ «КриптоПро CSP».

Запустите «КриптоПро CSP» и инсталлируйте ключевой считыватель Реестр для хранения контейнера с секретным ключом СА сертификата, как описано в разделе «Инсталляция ключевого считывателя Реестр в «КриптоПроCSP».

Для инсталляции Удостоверяющего Центра Microsoft Certification Authority запустите Server Manager (Start-Administrative Tools-Server Manager) и войдите в раздел Roles. Выберите Add Roles и инсталлируйте Web Server(IIS).

Затем, выполните инсталляцию Active Directory Certificate Services (Рисунок 16), которую опишем подробнее.