Инфраструктура управления открытыми ключами pki

Введение

Словарь терминов

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа, набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем… Приложения могут использовать CRL для подтверждения, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, является частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
• CPS (Certificate Practice Statement) — документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.

Модель доверия и архитектура PKI

Скрыть рекламу в статье

Модель доверия и архитектура PKI

Фундаментом доверия PKI являются надежные сертификаты открытых ключей. Надежность сертификатов открытых ключей зависит от надежности удостоверяющих центров, которые их подписывают. Это допущение формирует отношения доверия между различными сторонами — участниками системы PKI и позволяет конечным субъектам считать свои транзакции надежными.

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

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

При развертывании PKI сложной структуры организация должна определить, будет ли она доверять сертификатам пользователей и приложений только своего домена доверия или других доменов тоже. Как уже упоминалось ранее, домен доверия, или домен политик, характеризуется набором политик, в соответствии с которыми выпускает сертификаты данный УЦ. Если принимается решение о доверии ограниченному набору доменов, то должны быть выпущены кросс-сертификаты и тем самым внедрена в другие домены модель доверия данной организации. Если организация планирует использовать, например, приложение глобальной защищенной электронной почты,
то потребуется более сложная структура кросс-сертификации всех входящих в состав PKI удостоверяющих центров, способная обеспечить построение путей сертификации между любыми двумя владельцами сертификатов из любых доменов доверия.

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

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

В иерархической PKI ущерб от выхода из строя конкретного УЦ (например, из-за компрометации секретного ключа подписи УЦ) зависит от того, на каком уровне иерархии он находится. Чем ближе УЦ к верху иерархии, тем более разрушительны для всей PKI последствия его выхода из строя. Очевидно, что для защиты более высоких уровней иерархии, особенно головного УЦ, необходимы дополнительные меры безопасности, например, использование ключа подписи большей длины и/или хранение материала секретных ключей при помощи аппаратного модуля.

В настоящее время иерархическая модель, как правило, используется в web-среде, некоторые корпоративные домены также адаптируют ее. Считается, что иерархическая модель является хорошим механизмом контроля политики подчиненных удостоверяющих центров, но на самом деле аналогичные возможности контроля существуют и у кросс-сертифицированных удостоверяющих центров >.

Оглавление книги

Установка Root CA — или корневой CA

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

• Отправка новой заявки на сертификат;
• Публикация CRL;
• Обновление сертификата самого CA;
• Установка обновлений безопасности.

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

Перед установкой роли AD CS, необходимо создать конфигурационный файл, который будет использоваться установщиком роли. Для этого в папке %systemroot% необходимо создать файл с именем CAPolicy.inf и внести в него следующий текст:

 
Signature= "$Windows NT$"
 
; Устанавливаем длину ключа, которая будет использоваться 
; *только* при обновлении сертификата CA 
RenewalKeyLength = 2048 
; Устанавливаем срок действия обновлённого сертификата. 
; Будет использоваться *только* при обновлении сертификата CA 
RenewalValidityPeriodUnits = 20 
; Устанавливаем единицу измерения для предыдущего параметра 
RenewalValidityPeriod = years 
; Устанавливаем периодичность публикации CRL в днях 
CRLPeriodUnits = 365 
CRLPeriod = days 
; Устанавливаем срок продления CRL. Фактический срок действия CRL для клиентов увеличивается на 
; на заданный период, который в нашем случае равен 2 неделям.
CRLOverlapUnits = 2 
CRLOverlapPeriod = weeks 
; Отключаем публикацию Delta CRL 
CRLDeltaPeriodUnits = 0 
CRLDeltaPeriod = hours 
; Включаем дискретные алгоритмы для подписей. Не включайте его если у вас есть клиенты под управлением
; Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
;
AlternateSignatureAlgorithm = 1

• На странице Before You Begin вы можете ознакомиться с информацией об этом мастере. После ознакомления нажмите Next.
• На странице Select Roles выберите Active Directory Certificate Services и нажмите Next.
• На следующей странице прочтите вводную информацию о роли AD CS и нажмите Next.
• На странице Role Services убедитесь что установлен чек-бокс только напротив Certification Authority и нажмите Next.
• На странице Setup Type выберите Standalone. Поскольку компьютер не является членом домена, Enteprise нам недоступен. Нажмите Next.
• На странице выбора типа CA выберите Root CA и нажмите Next.
• На странице Private Key выберите Create a new private key и нажмите Next.
• На странице Cryptography выберите следующий криптопровайдер из списка: RSA#Microsoft Software Key Storage Provider
• Установите длину ключа в 2048 бит и алгоритм подписи в SHA256. После чего нажмите Next.
• На странице выбора имени CA введите следующее:
  Contoso Class 1 Root Certification Authority.
  в поле Distinguished name suffix укажите примерно такое:
  OU=Information Systems,O=Contoso
  и нажмите Next.
• На странице Validity Period укажите срок действия сертификата. В большинстве случаев 10 лет — наиболее оптимальный срок действия корневого сертификата. Нажмите Next.
• На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
• На странице Confirmation просмотрите настройки, которые вы указали. Если вы ошиблись на каком-то этапе — вернитесь назад и исправьте ошибку. Если всё правильно, нажмите Install и подождите пока мастер сконфигурирует роль.

Основные компоненты PKI

• Удостоверяющий центр он же и центр сертификации (УЦ или CA — Certificate Authority)
  является основной структурой, формирующей цифровые сертификаты подчиненных центров сертификации и
  конечных пользователей. УЦ является главным компонентом PKI:
  1. он является доверенной третьей стороной
  2. это сервер, который осуществляет управление жизненным циклом сертификатов (но не их непосредственным использованием).
• Сертификат открытого ключа (чаще всего просто сертификат) — это данные пользователя/сервера и его открытый ключ, скреплённые электронной подписью удостоверяющего центра. Выпуская сертификат открытого ключа, удостоверяющий центр тем самым подтверждает, что лицо, поименованное в сертификате, владеет закрытым ключом, который соответствует этому открытому ключу.
• Регистрационный центр (РЦ) — необязательный компонент системы, предназначенный для регистрации пользователей. Удостоверяющий центр доверяет регистрационному центру проверку информации о субъекте. Регистрационный центр, проверив правильность информации, подписывает её своим ключом и передаёт удостоверяющему центру, который, проверив ключ регистрационного центра, выписывает сертификат. Один регистрационный центр может работать с несколькими удостоверяющими центрами (то есть состоять в нескольких PKI), один удостоверяющий центр может работать с несколькими регистрационными центрами. Иногда, удостоверяющий центр выполняет функции регистрационного центра.
• Репозиторий — хранилище, содержащее сертификаты и

  (СОС) и служащее для распространения этих объектов среди пользователей. В Федеральном Законе РФ № 63 «Об электронной подписи» он называется реестр сертификатов ключей подписей.

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

Установка центра сертификации на предприятии. Часть 1 +18

• 22.02.18 09:18

•
sahsAGU
•
#348944
•
Хабрахабр

•
Tutorial

•

•

4400

Информационная безопасность, Системное администрирование, Серверное администрирование, Блог компании Microsoft, IT-инфраструктура
Рекомендация: подборка платных и бесплатных курсов системных администраторов — https://katalog-kursov.ru/

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Принципы работы PKI

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

Защита от атаки «Человек в середине»

При реализации атаки «человек в середине» злоумышленник может скрытно заменить передаваемые открытые ключи пользователей на свой открытый ключ, и создать разделяемые секреты с каждым из участников процесса, затем перехватить и расшифровать данные. На рис.1 рассмотрим этот процесс. Есть 2 пользователя А и В. У пользователя В есть открытый ключ K_pа для проверки ЭЦП пользователя А. Далее злоумышленник перехватит пакет при передаче его между пользователями с содержимым K_pi. На основе его он создаст свой K_pi` ключ и будет посредником между пользователями. Такая угроза решается с помощью сертификатов открытых ключей.

Сертификаты открытых ключей

Главная задача сертификата открытого ключа — сделать его достоверным и доступным. В основе сертификатов открытых ключей лежат принципы аутентификации, рекомендованные стандартом Х.509. Уровень достоверности аутентификации пользователя зависит от надежности хранения секретного ключа и надежности источника поставки открытых ключей. Чтобы пользователь мог доверять алгоритму аутентификации, он должен извлечь открытый ключ другого пользователя из достоверного источника, которому он доверяет. Согласно стандарту Х.509 является центр сертификации СА. Также его называют УЦ (удостоверяющий центр). Последняя аббревиатура встречается в законах стран СНГ.

Центр сертификации СА является третьей доверенной стороной, которая реализует аутентификацию открытых ключей, имеющихся в сертификатах. СА имеет личную пару ключей (секретный/открытый), где секретный ключ СА нужен для подписи сертификатов, а открытый ключ СА идет в открытый доступ и нужен пользователям для проверки подлинности ключа в сертификате.

Сертификация открытого ключа — это процесс подтверждения подлинности открытого ключа и хранимой вместе с ним служебной информации. Сертификация открытого ключа — это подписывание открытого ключа электронной подписью, сделанного на секретном ключе центра сертификации. СА создает сертификат открытого ключа пользователя с помощью создания цифровой подписи на основе набора данных пользователя. Стандарт Х.509 определяет этот список данных:

• серия и номер ключа
• период работы открытого ключа (начало и конец периода)
• уникальное имя пользователя
• данные об открытом ключе пользователя: идентификатор алгоритма и конкретно значение ключа

Сертификат открытого ключа имеет следующие характеристики:

• каждый пользователь, который имеет доступ к открытому ключа СА может извлечь открытый ключ, включенный в сертификат
• сертификаты нельзя подделать без обнаружения факта

Алгоритм генерации ключей может быть реализован 2 методами:

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

Планирование политик выдачи сертификатов

Определение политик

• Сертификаты для подписи электронной почты могут выдаваться автоматически с минимальной проверкой заявителя (только на основании успешной аутентификации пользователя в Active Directory). Никаких дополнительных действий для выпуска этих сертификатов не проводится.
• Сертификаты для цифровой подписи документов могут выдаваться только после согласования с непосредственным руководителем и предоставления письменной заявки со всеми необходимыми подписями.
• Сертификаты для смарт-карт могут выдаваться только при личном присутствии работника наряду с инструктажем по правилам использования карт, подписанием соответствующих регулирующих документов.
• Все пользователи могут получить сертификат аутентификации для доступа к беспроводной сети с мобильных устройств, но доступ к критическим системам будет разрешён, если аутентификация была выполнена только с помощью смарт-карт.

Network Policy Server (NPS)Active Directory Dynamic Access Control

Описание политик

Certificate Practice Statementописанный в RFC 3647

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

Программирование политик

Что в OID’е тебе моём?

• 1.3.6.1.4.1.x.1.1
• 1.3.6.1.4.1.x.1.2
• 1.3.6.1.4.1.x.1.3
• 1.3.6.1.4.1.x.1.4
• …

Extended ValidationCertificate Policies extension – all you should know (part 1)Certificate Policies extension – all you should know (part 2)

Термины, которые необходимы для общего понимания:

Сертификат открытого ключа
электронный документ удостоверенный электронной подписью удостоверяющего центра, содержащий открытый ключ, информацию о сроке его действия и владельце ключа.Закрытый ключ
ключ, известный только его владельцу, сгенерированный с помощью ассиметричного криптографического алгоритма, использующийся для электронной подписи данных и расшифровки данных зашифрованных на соответствующем этому закрытому ключу открытом ключе.Открытый ключ
ключ, создаваемый в паре с закрытым ключом с помощью ассиметричного криптографического алгоритма, используется для шифрования данных и проверки электронной подписи.Отпечаток открытого ключа (fingerprint/thumbprint)
информация, по которой можно идентифицировать открытый ключ. Отпечаток создаётся путём применения криптографической хеш-функции к значению открытого ключа.Подписанные данные
данные, подписанные при помощи закрытого ключа пользователя.Зашифрованные данные
данные, зашифрованные при помощи открытого ключа пользователя.Путь доверия
цепочка документов, которая позволяет удостовериться, что предъявленный сертификат был выдан доверенным центром; последним звеном в этой цепочке является предъявленный сертификат, начальным — сертификат корневого доверенного центра сертификации, а промежуточными — сертификаты, выданные промежуточным центрам сертификации. Особенностью пути доверия является то, что при потере доверия к начальному звену цепочки (корневому центру сертификации) теряется доверие ко всей цепочке, то есть ко всем выданным данным центром сертификатам и к предъявленному в том числе.Личные сертификаты
сертификаты которые хранятся у пользователя в личном хранилище сертификатов.Корневые центры сертификации
центры сертификации, которым доверяют изначально все, либо руководствуясь политикой предприятия, либо из-за предустановленных настроек хранилища сертификатов, и которые могут находиться в начале пути доверия.Доверенные центры сертификации
список центров сертификации, которым доверяют владельцы сертификатов. Чтобы сделать какой-либо центр доверенным, достаточно получить от него сертификат и внести его в список доверенных центров.

Общие положения

X.509

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

• Центр Сертификации (ЦС) – служба, предоставляющая цифровые сертификаты потребителям и обеспечивающая функционирование PKI.
• Сервер отзыва – служба, предоставляющая информацию о списках отозванных (скомпрометированных или недействительных) сертификатов, выпущенных конкретным ЦС.
• Клиент – получатель заверенного цифрового сертификата от центра сертификации. Клиентами могут выступать люди, устройства, программное обеспечение, а также другие ЦС.

Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева

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

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

ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.

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

Certificate Chaining Engine — how it works

Планирование имён ЦС

• Имя должно отражать название организации (можно и сокращённое) и роль конкретного ЦС в иерархии (атрибут CN, Common Name);
• Суффикс должен отражать название отдела или подразделения, которое отвечает за его управление в атрибуте OU (Organizational Unit);
• Дублировать полное название организации (атрибут O, Organization);
• Юридическое место дислокации ЦС. Для этого достаточно использовать атрибуты L (Locality) и C (Country). Как правило, это название города и страны, где юридически зарегистрирована организация. Если необходимо, можно указать штат/область посредством атрибута S (State).

• Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола . Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
• Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, a, z, U, ?). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола . Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

Планирование списков отзыва (CRL)

1. Точки публикации и распространения списков отзыва;
2. Состав и срок действия списков отзыва.

Точки публикации и распространения списков отзыва

• Для корневого ЦС указывается строго локальный путь, поскольку этот сервер будет изолирован от сети. Копирование файла на сервер распространения (IIS) будет производиться вручную. Это не проблема, поскольку периодичность публикации списков отзыва для корневого ЦС будет измеряться месяцами (об этом см. далее).
• Для издающих ЦС указывается сетевой путь. Я рекомендую создать общую папку в DFS, которую можно легко определить как виртуальную директорию в IIS. В этом случае процесс публикации физического файла в точку распространения будет полностью автоматизирован.
• Протокол LDAP не должен использоваться для публикации и распространения списков отзыва.

Designing CRL Distribution Points and Authority Information Access locations

Состав списков отзыва

Корневой ЦССправка: как посчитать планируемый размер файла CRL исходя из объёмов отзыва? Типичный пустой CRL занимает примерно 600-800 байт. Каждая запись об отозванном сертификате занимает 88 байт. Исходя из этих значений можно высчитать размер CRL в зависимости от количества отозванных сертификатов.Издающий ЦС

Планирование сроков действия CRL

• На какой срок следует публиковать список отзыва?
• Как долго информация в нём может считаться достоверной и достаточно актуальной?

How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2)На практике я достаточно часто наблюдал желание администраторов закрутить настройки сроков действия CRL до минимального предела с таким обоснованием: «пользователь уволился и не должен иметь возможность аутентифицироваться с отозванным сертификатом». Мотивация понятна, но решение задачи через списки отзыва не совсем правильно. В случае, если пользователю необходимо прекратить доступ к корпоративным системам, необходимо отключить учётную запись пользователя или компьютера.

• Все ЦС, которые выдают сертификаты только другим ЦС (не конечным потребителям), должны публиковать CRL сроком действия от 3-х до 12 месяцев с запасом в один месяц.
• Все ЦС, которые выдают сертификаты конечным потребителям (пользователям и устройствам), должны публиковать базовые CRL не реже одного раза в неделю и дифференциальные списки не реже 3-х дней (желательно, ежедневно). Запас по времени не следует корректировать (используйте тот, который будет автоматически высчитан внутренней логикой ЦС).

Online Certificate Status Protocol

Online Responder Installation, Configuration, and Troubleshooting GuideOptimizing the Revocation ExperienceCertificate Revocation Checking in Windows Vista and Windows Server 2008

Итоговая конфигурация

Корневой ЦС

Издающий ЦС

Сервер IIS