Contents of this directory is archived and no longer updated.

Posts on this page:

Устанавливаем Certification Authority (часть 4) — Конфигурирование Subordinate Issuing CA
Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA
Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA
Устанавливаем Certification Authority (часть 1) — Введение
Планирование расширений CDP и AIA

Устанавливаем Certification Authority (часть 4) — Конфигурирование Subordinate Issuing CA

Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в постустановочном скрипте

Ссылки на другие материалы из этой серии:

Устанавливаем Certification Authority — Подведение итогов

В предыдущей части (Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA) мы рассмотрели процесс установки Online Issuing Enterprise Subordinate CA, который так же выполняет роль Policy CA. Теперь нам осталось осталось сконфигурировать этот центр сертификации и параметры в Active Directory. По аналогии с конфигурированием Offline Root CA мы будем использовать post-installation script.

Step 1 — developing post-installation script

:: Создаём папку в корне диска C, где будут храниться CRT и CRL файлы
md C:\CertData

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: конфигурирование параметров CA ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_PICA%%8%%9.crl\n6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_PICA%%4.crt\n32:http://www.{adatum.com}/ocsp"

:: Поскольку мы не можем управлять публикацией CRT файлов, мы его
:: переименовываем в нужное имя и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt {Adatum}_PICA.crt
copy %windir%\system32\CertSrv\CertEnroll\{Adatum}_PICA.crt C:\CertData

:: задаём максимальный срок действия издаваемых сертификатов равным 5 лет
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)
certutil -setreg CA\CRLPeriodUnits 5
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 1

:: Включаем наследование Issuer Statement в издаваемых сертификатах
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"

:: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.

:: Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1

:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: конфигурирование параметров AD ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: задаём контекст конфигурации для сервера CA. Контекст конфигурации
:: должен указывать на *корневой домен* текущего леса.
certutil -setreg CA\DSConfig "CN=Configuration,DC={adatum},DC={com}"

:: публикуем сертификат CA в AD
certutil -dspublish -f C:\CertData\{Adatum}_PICA.crt Subca
certutil -dspublish -f C:\CertData\{Adatum}_PICA.crt NTAuthCA

net stop certsvc && net start certsvc

:: Публикуем новый CRL в новую локацию.
certutil –CRL

Примечание: как и раньше, вы должны заменить на свои значения всё, что помещено в фигурные скбоки {}.

Step 2 — Configuring Web Server

Как вы знаете, у нас будут использоваться HTTP ссылки для скачивания файлов CRT/CRL. Для этого нужно настроить соответствующим образом ваш корпоративный веб-сервер. А именно, создать виртуальную директорию (внутри сайта с заголовком www.adatum.com) и в качестве физического пути указать на папку C:\CertData.

Примечание: если ваш веб-сервер работает под управлением IIS 7 и выше, убедитесь, что сервер настроен на двойной эскейпинг для корректного восприятия знака плюс (+) в ссылках. DoubleEscaping можно включить руководствуясь этой ссылкой: Configure Request Filters in IIS 7.

Step 3 — Setup OCSP Responder

В нашем сценарии предполагается, что мы будем использовать OCSP Responder для Issuing CA и, опционально, для Root CA. OCSP Responder для Issuing CA настраивается следующим образом:

Примечание: пост-установочный скрипт уже сконфигурировал расширение AIA включив ссылку на OCSP. Следовательно, настройку этого расширения на сервере CA можно опустить.

Когда OCSP для Issuing CA будет сконфигурирован, можно дополнительно сконфигурировать его и для Root CA (при условии, что корневой CA настроен на публикацию ссылок OCSP в издаваемых сертификатах. Об этом см. секцию Step 3 статьи Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA).

Если в post-installation скрипте вы указали ссылку на OCSP, сертификат Issuing CA её должен содержать в расширении Authority Information Access. Для обеспечения работоспособности этой ссылки необходимо создать ещё одну конфигурацию в OCSP. Для этого выполните следующее:

Откройте оснастку Online Responder из папки Administrative Tools.
Выделите Revocation configuration и в меню Action выберите Add Revocation Configuration.
Откроется мастер создания конфигурации отзыва. Ознакомьтесь с предстоящими шагами и нажмите Next.
Укажите имя новой конфигурации. Например: RootCA 1. Единичка будет означать номер ключа CA для которого настроена конфигурация. Дело в том, что при каждом обновлении сертификата CA с новой ключевой парой вам необходимо будет создавать новую конфигурацию в OCSP. Нажмите Next.
На странице Select CA Certificate Location выберите Import certificate from a file и нажмите Next.
На следующей странице укажите путь к файлу сертификата корневого CA и нажмите Next.
На странице Select Signing Certificate укажите Manually select signing certificate и нажмите Next.
На странице Revocation Provider вы можете получить сообщение об ошибке, которая сообщает о том, что мастер не смог получить сведения о конфигурации CA. Это связано с тем, что наш Offline Root CA не подключен к сети и вообще находится в сейфе. Поэтому нажмите кнопку Provider и укажите ссылку на CRL корневого центра сертификации. По условиям нашего сценария, ссылка будет иметь следующий вид:
http://www.adatum.com/pki/Adatum_RCA.crl

Поскольку корневой CA не использует Delta CRL, оставьте это поле пустым. Так же вы можете настроить периодичность, с которой OCSP будет освежать свой внутренний кеш. Например, можно указать каждые 10 минут. Нажмите Ok и вернитесь в мастер создания конфигурации OCSP.
Нажмите Finish для завершения работы мастера.

Вы вернётесь обратно в оснастку OCSP Responder и увидите, что наша созданная конфигурация выдаёт ошибку, поскольку нет сертификата подписи, который будет использоваться для подписи ответов OCSP. Для устранения этого недостатка, разверните секцию Array Configuration и выделите нужный респондер (предполагается, что это тот же самый сервер, на котором вы настраиваете OCSP). В центральной панели выберите конфигурацию RootCA 1 и в панели Actions нажмите на Assign Signing Certificate. Откроется список пригодных сертификатов. Скорее всего он там будет один. Поэтому выберите его и нажмите Ok.

Теперь выделите Array Configuration и в меню Action нажмите Refresh Revocation Data. И вот что вы должны увидеть в конечном итоге:

OCSP Responder configurations

Results

Для окончательной проверки мы можем запустить оснастку PKIView.msc. Если мы настроили всё правильно, то должны увидеть примерно такой вид:

Reviewing CA installation results

И подведём итоги того, что мы сделали:

Мы спланировали типовую 2-х уровневую иерархию и конфигурацию PKI, которая включает в себя Offline Root CA и Online Issuing CA;
Установили и сконфигурировали соответствующим образом наш корневой Root CA, который может быть нормально выключен и который будет издавать сертификаты только для других центров сертификации;
Установили и сконфигурировали подчинённый Issuing CA, который будет издавать сертификаты уже конечным потребителям.
Настроили OCSP Responder для работы с Offline Root CA.

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

1 TXT file
2.3 KB PICA_postscript.cmd

(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)

Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA

Update 03.04.2010: добавлен OID для PolicyStatementExtension.

Update 26.06.2011: добавлена публикация корневого сертификата в Active Directory.

Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf. Обязательно прочтите.

Ссылки на другие материалы из этой серии:

Устанавливаем Certification Authority — Подведение итогов

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

Несколько слов о роли Policy CA. Технически Policy CA выражается расширением Certificate Policies в сертификате CA. Данное расширение содержит ссылку на страницу загрузки CPS (Certificate Practice Statement). CPS — юридический документ, регламентирующий работу центров сертификации компании, включающий в себя наиболее важные части:

Описание организации иерархии PKI, её состав и меры защиты, принятые для обеспечения физической безопасности серверов CA;
Уровни ответственности и assurance для издаваемых сертификатов.
Описание процедуры подачи заявки на сертификат. Этот пункт включает описание мероприятий, применяемых для идентификации реквестора (кто запрашивает сертификат), методы подачи заявки (автоэнроллмент, Web Enrollment Pages, отправка по электронной почте и др.);
Описание процедуры отзыва сертификатов. Этот пункт включает порядок получения заявки на отзыв, идентификация реквестора, порядок отзыва сертификатов и порядок публикации CRL;
Описание процедур при решении организационных и технических вопросов.

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

Примечание: кросс-сертификация (cross-certification) является процедурой и механизмом доверия одной компанией PKI другой компании. Вопросы кросс-сертификации выходят за рамки рассматриваемого материала.

Каждой уважающей себя компании использующей PKI необходимо иметь такой документ. Для облегчения процесса написания CPS вы можете воспользоваться рекомендациями RFC 3647: http://tools.ietf.org/html/rfc3647, а так же посмотреть аналогичные документы коммерческих CA (например: https://www.verisign.com/repository/cps/index.html) и переложить их под свои условия.

В данном посте я не буду обсуждать вопросы CPS, а только покажу как информация о CPS прикрепляется к сертификату CA. Однако, хочу заметить, что для использования CPS, вы ему должны назначить свой OID, который принадлежит вашей компании. Более подробно об OID'ах здесь: Что в OID'е тебе моём?

Step 1 — Preparing Subordinate Issuing CA

Предполагается, что компьютер с именем IssuingCA установлен, обновлён и сконфигурированы параметры безопасности. Данный компьютер является членом домена Active Directory с именем Adatum.com. Данный компьютер будет выполнять роль издающего центра сертификации (Issuing Certification Authority) с совмещением роли Policy CA. Данный центр сертификации будет постоянно подключен к сети и обслуживать заявки на сертификаты от непосредственных потребителей.

Вводные данные для издающего сервера CA:

Имя CA — Adatum Class 1 Issuing SubCA 1;
Тип CA — Subordinate Enterprise.
Срок действия сертификата CA — 10 лет;
Срок действия издаваемых сертификатов — не более 5 лет;
Срок действия Base CRL — 5 дней ;
Срок действия Delta CRL — 12 часов;
Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с: Планирование расширений CDP и AIA;
CDP и AIA будут использовать только ссылки на HTTP. LDAP использоваться не будет.
OCSP для Issuing CA предусмотрен.

Step 2 — Installing AD CS role on Subordinate Issuing CA

Примечание: все операции выполняемые на сервере, который будет держать роль Issuing CA необходимо выполнять с правами Enterprise Admins.

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

[Version]
Signature = "$Windows NT$"

[PolicyStatementExtension]
Policies = {Adatum}CPS

[{Adatum}CPS]
URL = http://www.{adatum.com}/pki/policies.html
OID = 2.5.29.32.0

[certsrv_server]
; Устанавливаем длину ключа, которая будет использоваться
; *только* при обновлении сертификата CA
RenewalKeyLength = 2048
; Устанавливаем срок действия обновлённого сертификата.
; Будет использоваться *только* при обновлении сертификата CA
RenewalValidityPeriodUnits = 10
; Устанавливаем единицу измерения для предыдущего параметра
RenewalValidityPeriod = years
; Устанавливаем периодичность публикации CRL в 5 дней
CRLPeriodUnits = 5
CRLPeriod = days
; Устанавливаем срок продления CRL. Фактический срок действия CRL для клиентов увеличивается на
; на заданный период, который в нашем случае равен 2 неделям. Это означает, что сервер CA будет
; публиковать новый CRL каждые 90 дней, а срок действия этого CRL будет 104 дня. Это даст
; администраторам возможность успеть забрать новый CRL с сервера и распространить его в нужные локации
CRLOverlapUnits = 1
CRLOverlapPeriod = days
; Устанавливаем периодичность публикации CRL в 12 часов
CRLDeltaPeriodUnits = 12
CRLDeltaPeriod = hours

:: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.

:: AlternateSignatureAlgorithm = 1

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

Когда конфигурационный сохранён в нужном месте, можно приступать к установке роли CA. Для этого запустите Server Manager, перейдите на секцию Roles и нажмите Add Roles. После этого запустится мастер установки ролей.

Примечание: если у вас используется HSM (Hardware Security Module), его драйвер должен быть установлен заранее. И на шаге 8 в списке криптопровайдеров необходимо выбрать CSP производителя вашего HSM.

Примечание: в ходе установки роли AD CS на шаге 9 вместо Adatum укажите название вашей компании. Места, в которых необходимо прописать свои данные заключены в фигурные скобки — {}.

На странице Before You Begin вы можете ознакомиться с информацией об этом мастере. После ознакомления нажмите Next.
На странице Select Roles выберите Active Directory Certificate Services и нажмите Next.
На следующей странице прочтите вводную информацию о роли AD CS и нажмите Next.
На странице Role Services убедитесь что установлен чек-бокс только напротив Certification Authority и нажмите Next.
На странице Setup Type выберите Enterprise и нажмите Next.
На странице выбора типа CA выберите Subordinate CA и нажмите Next.
На странице Private Key выберите Create a new private key и нажмите Next.
На странице Cryptography выберите следующий криптопровайдер из списка: RSA#Microsoft Software Key Storage Provider
Установите длину ключа в 2048 бит и алгоритм подписи в SHA1. После чего нажмите Next.
На странице выбора имени CA введите следующее:
{Adatum} Class 1 Issuing SubCA 1.
в поле Distinguished name suffix укажите примерно такое:
OU=Information Systems,O={Adatum Ltd.},C={LV}
и нажмите Next.
На странице Certificate Request установите переключатель на Save certificate request и укажите путь размещения файла запроса. Поскольку наш корневой CA недоступен из домена, мы сохраним файл запроса и отправим его на корневой сервер. Нажмите Next.
На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
На странице Confirmation просмотрите настройки, которые вы указали. Если вы ошиблись на каком-то этапе — вернитесь назад и исправьте ошибку. Если всё правильно, нажмите Install и подождите пока мастер сконфигурирует роль.
На странице Results ознакомьтесь с результатами установки и необходимыми шагами для завершения установки. Закройте мастер кнопкой Close.

Step 3 — Completing Subordinate Issuing CA installation

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

Запустите оснастку Certification Authority из папки Administrative Tools.
Выделите секцию с именем CA, нажмите Action –> All Tasks –> Submit new request.
В диалоговом окне укажите файл запроса, который был сгенерирован на этапе установки Issuing CA.
Теперь запрос находится в очереди ожидания.
Перейдите в секцию Pending Requests, выделите нужный запрос (он там скорее всего будет единственный), нажмите правой кнопкой и нажмите Issue.
Должно появиться диалоговое окно сохранения файла сертификата. Сохраните сертификат в папке C:\CertData.
Если диалоговое окно автоматически не появилось, перейдите в секцию Issued certificates, откройте сертификат, перейдите на вкладку Details и там нажмите кнопку Copy to file. Сохраните файл в папку C:\CertData.
Скопируйте всё содержимое папки C:\CertData на съёмный носитель.
Выйдите из системы или выключите сервер. На данном этапе в следующий раз наш Offline Root CA потребуется включить через 3 месяца для публикации нового CRL или когда потребуется отправить ещё один запрос или отозвать какой-то сертификат.

Вернитесь на Issuing CA для завершения инсталляции.

Скопируйте файлы со съёмного носителя (содержимое папки CertData, которое вы скопировали на предыдущем этапе) на локальный диск. Например, в ту же папку C:\CertData.
Запустите консоль CMD с расширенными привилегиями (elevated mode) и выполните в ней следующие команды:
certutil –addstore Root C:\CertData\Adatum_RCA.crt
certutil –addstore Root C:\CertData\Adatum_RCA.crl
certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA

где Adatum_RCA.crt — файл сертификата корневого центра сертификации. Его нужно установить для обеспечения доверия этому и другим сертификатам в его цепочке.
где Adatum_RCA.crl — файл списка отзыва корневого центра сертификации. Его нужно установить для обеспечения возможности проверки сертификатов на отзыв. В противном случае при установке Issuing CA, он не сможет проверить на отзыв свой собственный сертификат.
Убедитесь, что ошибок не произошло. Если это так, закройте консоль CMD.

Теперь можно установить сертификат на сервер CA. Для этого запустите оснастку Certification Authority из папки Administrative Tools. В оснастке выделите имя центра сертификации, нажмите Action –> All tasks –> Install CA certificate. В диалоговом окне перейдите на папку C:\CertData и укажите файл SubCA1.cer и нажмите Open. Если импорт прошёл без ошибок, сертификат CA был установлен успешно. Но запускать службу Certificate Services ещё рано.

Нам осталось написать и выполнить послеустановочный скрипт, который сконфигурирует сервер CA и подготовит AD к успешной работе. Но об этом в следующий раз.

1 TXT file
852.0 bytes PICA_CAPolicy.inf

(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)

Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA

Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf и пост-конфигурационном скрипте. Обязательно прочтите.

Ссылки на другие материалы из этой серии:

Устанавливаем Certification Authority — Подведение итогов

В первой части установки Certification Authority мы рассмотрели общие вопросы планирования иерархии центров сертификации для сферических задач в вакууме. Я намерено опустил организационные вопросы, которые тоже должны решаться на этапе планирования и остановился лишь на технических аспектах планирования. Итак, как мы договорились в первой части, у нас будет двухуровневая иерархия с Offline Root CA и Online Issuing Subordinate CA.

Step 1 — Preparing to install

Примечание: по различым причинам я не описываю процедуру установки и настройки Certificate Services на систему под управлением Windows Server 2003. Многое из изложенного будет справедливо и для Windows Server 2003, но часть из этого не будет справедливо для него.

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

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

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

Вводные данные для корневого сервера CA:

Имя CA — Adatum Class 1 Root Certification Authority;
Тип CA — Standalone.
Срок действия сертификата CA — 10 лет;
Срок действия издаваемых сертификатов — 10 лет;
Срок действия Base CRL — 90 дней (3 месяца);
Delta CRL публиковаться не будет;
Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с: Планирование расширений CDP и AIA;
CDP и AIA будут использовать только ссылки на HTTP. LDAP использоваться не будет.
OCSP для Offline Root CA предусмотрен.

Step 2 — Installing AD CS role on Offline Root CA

[Version]
Signature= "$Windows NT$"

[certsrv_server]
; Устанавливаем длину ключа, которая будет использоваться
; *только* при обновлении сертификата CA
RenewalKeyLength = 2048
; Устанавливаем срок действия обновлённого сертификата.
; Будет использоваться *только* при обновлении сертификата CA
RenewalValidityPeriodUnits = 10
; Устанавливаем единицу измерения для предыдущего параметра
RenewalValidityPeriod = years
; Устанавливаем периодичность публикации CRL в 90 дней (или 3 месяца)
CRLPeriodUnits = 90
CRLPeriod = days
; Устанавливаем срок продления CRL. Фактический срок действия CRL для клиентов увеличивается на
; на заданный период, который в нашем случае равен 2 неделям. Это означает, что сервер CA будет
; публиковать новый CRL каждые 90 дней, а срок действия этого CRL будет 104 дня. Это даст
; администраторам возможность успеть забрать новый CRL с сервера и распространить его в нужные локации
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 бит и алгоритм подписи в SHA1. После чего нажмите Next.
На странице выбора имени CA введите следующее:

{Adatum} Class 1 Root Certification Authority.

в поле Distinguished name suffix укажите примерно такое:

OU=Information Systems,O={Adatum Ltd.},C={LV}

и нажмите Next.
На странице Validity Period укажите срок действия сертификата. В большинстве случаев 10 лет — наиболее оптимальный срок действия корневого сертификата. Нажмите Next.
На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
На странице Confirmation просмотрите настройки, которые вы указали. Если вы ошиблись на каком-то этапе — вернитесь назад и исправьте ошибку. Если всё правильно, нажмите Install и подождите пока мастер сконфигурирует роль.

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

Примечание: у вас может быть соблазн выбрать более стойкий алгоритм подписи. Например, SHA256 или SHA384. Однако, следует учесть, что предыдущие системы (например, Windows XP/Server 2003) могут испытывать трудности с проверкой подписей с использованием алгоритмов SHA-2. Более подробно можно почитать тут: http://blogs.msdn.com/alejacma/archive/2009/01/23/sha-2-support-on-windows-xp.aspx

Когда мастер установит роль AD CS, вы можете уже запустить оснастку Certification Authority из папки Administrative Tools. Однако, на этом ещё не всё закончилось. Сейчас нам необходимо применить скрипт, который сконфигурирует остальные настройки.

Step 3 — Finalizing Offline Root CA installation

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

Примечание: места в которых необходимо подставить свои данные заключены в фигурные скобки — {}.

:: Создаём папку в корне диска C, где будут храниться CRT и CRL файлы
md C:\CertData

:: Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_RCA%%8.crl\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%8.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt"

:: Если будет использоваться OCSP для корневого CA, расширение AIA должно выглядеть примерно cледующим образом:
:: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt\n32:http://www.{adatum.com}/ocsp"
:: учтите, что при использовании этого варианта, предыдущую строку требуется закомментировать или удалить
:: а эту строку раскомментировать соответственно.

:: Поскольку мы не можем управлять публикацией CRT файлов, мы его
:: переименовываем в нужное имя и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt {Adatum}_RCA.crt
copy %windir%\system32\CertSrv\CertEnroll\{Adatum}_RCA.crt C:\CertData

:: задаём срок действия издаваемых сертификатов равным 10 лет
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)
certutil -setreg CA\CRLPeriodUnits 90
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2

:: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
:: Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1

:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127

:: Включаем поддержку сертификатов OCSP Response Signing на Offline CA:
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

net stop certsvc && net start certsvc

:: Публикуем новый CRL в новую локацию.
certutil -CRL

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

Данный скрипт создаст в корне диска C: папку CertData, в которой будут храниться опубликованные списки CRL и файлы сертификатов сервера CA. При этом CRL'ы будут автоматически публиковаться в эту папку, а CRT нет. Это связано с тем, что начиная с Windows Server 2003 мы больше не имеем возможности управлять публикацей файлов CRT. Для этого мы берём файл из оригинальной папки CertEnroll, переименовываем в нужное нам имя и копируем в папку CertData. Здесь я ещё хочу остановиться на построении ссылок в CDP и AIA, поскольку они выглядят предельно ужасно. Давайте разберёмся с этим.

Step 4 — Understanding post-installation script

Возьмём следующую строку:

"65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\Adatum_RCA%%8.crl\n2:http://www.adatum.com/pki/Adatum_RCA%%8.crl"

Как мы видим, данная строка строится из 3-х составляющих:

65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl
65:C:\CertData\Adatum_RCA%%8.crl
2:http://www.adatum.com/pki/Adatum_RCA%%8.crl

Каждое составляющее является отдельной ссылкой, которую видно во вкладке Extensions свойств сервера CA в оснастке CertSrv.msc. Все эти составляющие пишутся в одну строку и разделяются символом новой строки: \n. Парсер CMD автоматически режет строку на куски по знаку новой строки. Когда мы разложили строку на более читабельные ссылки, пора и заняться ими. Первое, что нам бросается в глаза — это циферки перед ссылками. Циферки означают сумму параметров публикации. Т.е. что данная ссылка будет делать, публиковать физический файл, добавляться в расширение сертификатов или в расширение CRL и т.д. Это эквивалентно галочкам во вкладке Extensions. Каждая такая галочка имеет определённый числовой эквивалент (числовое значение). Предлагаю 2 таблички, которые покажут соответствие каждой галочке числовому значению для ссылок в расширении CDP и AIA:

Название галочки в CDP	Числовое значение	Название галочки в AIA	Числовое значение
Publish CRLs to this location.	1	Include in the AIA extension of issued certificates.	2
Include in the CDP extension of issued certificates.	2	Include in the Online Certificate Status Protocol (OCSP) extension.	32
Include in CRLs. Clients use this to find Delta CRL locations.	4
Include in all CRLs. Specifies where to publish in AD DS when publishing manually.	8
Publish Delta CRLs to this location.	64
Include in the IDP extension of issued CRLs.	128

Как видите, для расширения CDP число 65 является суммой чисел 1 и 64. Исходя из таблички мы можем узнать, что ссылка с таким префиксом публикует физические файлы для Base и Delta CRL. А цифра 2 (в третьей ссылке) означает, что эта ссылка будет добавляться в расширение CDP издаваемых сертификатов. Префикс ставится всегда перед самой ссылкой и отделяется от неё двоеточием — :. То же самое и касается ссылок в AIA.

Теперь осталось разобраться со знаками процента (%) и цифрами после них. Например: %windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl. Данные кракозябры представляют переменные, которые вы можете указывать при создании ссылок. Вот ещё одна табличка, которая показывает соответствие переменных их числовым значениям:

Примечание: данные значения справедливы как для расширения CDP, так и AIA.

Переменная в редакторе расширений CDP и AIA	Переменная в скрипте	Используемое расширение
<ServerDNSName>	%1	CDP/AIA
<ServerShortName>	%2	CDP/AIA
<CaName>	%3	CDP/AIA
<CertificateName>	%4	AIA
<ConfigurationContainer>	%6	CDP/AIA
<CATruncatedName>	%7	CDP/AIA
<CRLNameSuffix>	%8	CDP
<DeltaCRLAllowed>	%9	CDP
<CDPObjectClass>	%10	CDP
<CAObjectClass>	%11	CDP/AIA

Особо пытливые умы должны заметить, что в таблице указан один знак процента, а в скрипте по два знака. Никакой магии здесь нет, просто парсер CMD использует проценты для других целей. Следовательно, чтобы парсер CMD его не удалил, знак процента необходимо заэскейпить другим знаком процента. Более подробно об этих переменных и их значениях можно прочитать здесь:

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

Вот и всё, что я хотел рассказать про установку Offline Root CA. В следующей части я расскажу про установку Online Issuing CA и что-нибудь ещё.

Файлы для скачивания:

1 TXT file
995.0 bytes RCA_CAPolicy.inf

1 TXT file
2.0 KB RCA_postscript.cmd

(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)

Устанавливаем Certification Authority (часть 1) — Введение

Update 11.11.2010: Windows Server 2008 R2 Standard не поддерживает роль OCSP Responder.

Ссылки на другие материалы из этой серии:

Устанавливаем Certification Authority — Подведение итогов

Prologue

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается. К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> ????? –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI. Вот один из примеров: Помогите установить и настроить службу сертификации. Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка PKI кажется задачей не сложнее администрирования нотепада и укладывается по времени в промежуток обеденного перерыва. При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI (Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC. Я не претендую на попытку устранить этот пробел, поскольку это нереально, но стараюсь дать какие-то полезные понятия и какие-то другие вещи в соответствии с бест-практисами.

PKI tasks

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

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

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

Planning CA hierarchy

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

2-tier CA hierarchy

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

2-tier CA hierarchy

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

Planning CA types

Microsoft поддерживает два типа центров сертификации — Standalone и Enterprise. Обычно администраторы привыкли устанавливать Enterprise CA и по очевидным причинам не используют Standalone CA. Чем они отличаются?

Standalone

Характеризуются нетребовательностью к наличию домена Active Directory. Так же Standalone CA не использует шаблоны, следовательно вы не можете запрашивать сертификаты на таком CA через оснастку Certificates консоли MMC. Что означает, что вы не можете пользоваться функциями autoenrollment'а. Так же при выдаче сертификатов, Standalone CA не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера. Энролить сертификаты в Standalone CA можно только через Enrollment Web Pages, либо вручную генерируя запросы (файлы с расширением .req) и отправляя их через оснастку CertSrv.msc. Причём отправка запросов через оснастку CertSrv.msc является новой возможностью в Windows Server 2008. В связи с этим необходимость в Enrollment Web Pages отпала совсем.

По своим возможностям Standalone CA выглядит убогим чуть более, чем полностью. Но этот тип CA имеет одно сильное преимущество — он не зависит от наличия домена. Кажется — фигня. Домены даже рулят и педалят и всё, что работает без домена не нужно! Но давайте посмотрим на ситуацию немного с другой стороны. Центры сертификации верхних уровней (корневые и подчинённые центры сертификации первого уровня) имеют как правило очень большой срок действия — от 10 до 20 лет. При этом очень часто домены и леса AD живут значительно меньше, поскольку они постоянно реструктуирутся, переименовываются, мигрируются и т.д. А центр сертификации в домене (Enteprprise CA) лишает нас некоторых возможностей, как переименование домена и усложняют процессы реструктуризации доменов и лесов. По этой причине, Enterprise CA имеет небольшой срок действия своих сертификатов — от 5 до 10 лет максимум. В принципе, если есть независимый от домена AD центр сертификации (Standalone CA в рабочей группе) гораздо проще проводить миграцию и реструризацию лесов AD, поскольку эти процессы не затрагивают корневой CA и избавляют от проблем построения новой иерархии PKI. В такой ситуации достаточно только сменить центры сертификации 2-го и 3-го уровней (последний обычно является Enterprise CA). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

Enterprise

Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на Standalone CA по своим возможностям. Во-первых Enterprise CA требует наличия домена для хранения там своей информации и шаблонов сертификатов. Данный тип CA имеет очень большие возможности по выдаче и обслуживанию сертификатов. Enterprise CA не требует генерации файлов запросов со стороны клиентов, а позволяет подавать заявки на сертификаты через оснастку Certificates консоли MMC и автоматически распространять сертификаты в масштабах целого леса AD при минимальном участии конечного пользователя. Чаще всего это участие сводится к настройке администратором политик autoenrollment'а и всё. Плюс, Enterprise CA может публиковать сертификаты в свойства учётных записей пользователей и компьютеров.

Однако, зависимость от домена вносит некоторые ограничения в свою жизнь. Поскольку домены достаточно подвижные единицы и подвержены изменениям, Enterprise CA имеют достаточно короткий срок действия своих сертификатов — от 5 до 10 лет максимум. В случае Enterprise Root CA, удаление домена автоматически ведёт к краху всей иерархии PKI и её придётся строить с нуля, что может вылиться в большие трудности в довесок к текущим проблемам удаления домена. Именно поэтому компании никогда не устанавливают корневой центр сертификации на Enterprise CA, а только Issuing CA, которые уже издают сертификаты конечным потребителям, где и восстребованы все возможности Enterprise CA. Хотя, в очень небольших компаниях этого будет вполне достаточно, когда корневой CA устанавливается на Enterprise CA и имеет срок действия сертификата 5 лет.

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

Planning validity periods

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

Planning CDP/AIA extensions

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

Исходя из описанного по ссылкам (читать обязательно!) мы полностью откажемся от LDAP-ссылок и в сертификатах будем публиковать только ссылки на HTTP. Для этой цели нам потребуется веб-сервер, который будет хранить наши CRL/CRT файлы и поддерживать работоспособность ссылок. Поскольку корневой CA не будет издавать сертификаты конечным потребителям, а только для других CA, риск компрометации которых невелик (но всё же существует) и он большую часть времени будет выключен, мы отключим публикацию Delta CRL для корневого CA, но включим для Issuing CA. Основной CRL (Base CRL) мы будем публиковать каждые 3 месяца для корневого сертификата и каждые 5 дней для Issuing CA. Для обеспечения более быстрой реакции на отзыв сертификатов, для Issuing CA будем публиковать Delta CRL каждые 12 часов.

Так же можно предусмотреть использование OCSP (Online Certificate Status Protocol). Хоть обычно OCSP и используется только для Enterprise CA, ничего не мешает использовать его для корневого CA. С учётом роста количества клиентов под управлением Windows Vista и выше, это будет хороший экспериенс и я расскажу, как это можно будет реализовать.

Conclusion

Исходя из вышесказанного мы можем сформулировать программные требования для нашей иерархии PKI:

Windows Server 2008/2008 R2 Standard Edition.
Компьютер является членом рабочей группы WORKGROUP, с именем хоста RootCA. Компьютер не подключен к локальной сети или к интернетам. В принципе, для это задачи можно использовать и Enterprise/Datacenter редакции, но от них вы никакого профита не получите в случае использования роли ADCS (Active Directory Certificate Services). Редакции Standard хватит вполне.
Windows Server 2008 Enterprise/Datacenter или Windows Server 2008 R2 Standard/Enterprise/Datacenter.
Компьютер является членом домена Adatum.com с именем хоста Issuing CA. Компьютер не должен держать роль контроллера домена.
Домен Adatum.com содержит выделенный веб-сервер под управлением любой ОС и который доступен из интернета (только для обслуживания внешних клиентов).
Домен Adatum.com содержит сервер способный выполнять роль OCSP Responder'а. Если это будет Windows Server, требования к версии будут такие же, как и для Enterprise CA. Т.е. Windows Server 2008 R2 Standard/Enterprise/Datacenter или Windows Server 2008 Enterprise/Datacenter.

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

Планирование расширений CDP и AIA

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

Примечание: перед проведением любых изменений, описываемых в этом посте, обязательно выполните бэкап.

Большинство администраторов при установки роли Active Directory Certificate Services (AD CS) делают очень просто Next –> Next –> ????? –> PROFIT. С одной стороны это и хорошо, но часто это не очень хорошо. Чем это хорошо — оно будет работать. Чем это плохо — при появлении каких-то специфических условий (например, внешние по отношению к текущему лесу клиенты) оно начинает работать хуже и даже перестаёт быть работоспособным. Сегодня я планирую рассмотреть эти вопросы, как нестанадртные клиенты (не поддерживающие LDAP) и внешние клиенты, тем более это достаточно распространённый сценарий.

Отсебятина 1 — именование файлов

Небольшой вбросик. Я думаю, что многие замечали как именуются файлы. Например, дефолтный CRT имеет имя следующего формата:

<ServerDNSName>_<CAName><CertificateName>.crt

Т.е. обычно это выглядит так: caserver.company.com_companyca.crt. Скажем, не всем нравится такой формат, поскольку имя файла достаточно длинное и раскрывает внутреннее имя сервера, на котором хостится служба CA. Лично мне нравится другой формат имён файлов — короткое имя компании и аббревиатурное значение роли конкретного сервера CA. Например: company_RCA.crt. Мне кажется, что это хороший выбор. Однако, ни стандартный интерфейс CertSrv.msc, ни реестр не предоставляют возможности изменять имя и путь публикации CRT файла. Учитывая, что сертификаты самих CA обновляются достаточно редко, эту операцию можно выполнить вручную или при помощи скрипта — это уже на ваш выбор. Так что с CRT ничего не остаётся как копировать его вручную на веб-сервер или гонять его по DFS и переименовывать самостоятельно. Однако, следует учесть, что если сертификат CA обновлялся с новой ключевой парой, в конце имени файла добавляется число в круглых скобках. Например: server.domain.com_CAName(1).crt. Вот эта циферка приходит из <CertificateName>. Именно поэтому когда вы будете имзенять ссылку (об этом чуть ниже), которая будет публиковаться в издаваемых сертификатах, не забудьте к имени файла добавить <CertificateName>.

То же самое будет касаться и CRL. В соответствии с параграфом § 3.2.5.1.6 спецификации протокола [MS-CSRA]:

1.When this method is invoked, the CA SHOULD create a new base and/or delta CRL for each CA key, as specified in the following steps 2, 3, 4, 5, 6, and 7. The type of CRL to create (base, delta, or both) for each CA key is determined as follows:<38>

The CA SHOULD create a new base CRL for each CA key.

If the CA has enabled delta CRLs, as indicated by a nonzero Config_Delta_CRL_Validity_Period value, the CA MUST create a new delta CRL in addition to a new base CRL, for each CA key.

If delta CRLs are currently disabled (Config_Delta_CRL_Validity_Period is 0) and were enabled previously (Previous_Delta_CRL_Validity_Period is not equal to zero), the CA MUST create a new delta CRL in addition to a new base CRL for each CA key.

отдельный CRL создаётся для каждой ключевой пары CA. Следовательно, в имени CRL файлов следует оставить значение <CRLNameSuffix>. Этим самым сервер CA при публикации CRL на это место установит версию сертификата, для которого публикуется CRL. Например: CAName(1).crl и CAName(1)+.crl (для Base и Delta CRL). Если сертификат CA ещё не обновлялся, <CRLNameSuffix> будет заменён на пустое значение.

Устанавливаем Certification Authority (часть 4) — Конфигурирование Subordinate Issuing CA

Step 1 — developing post-installation script

Step 2 — Configuring Web Server

Step 3 — Setup OCSP Responder

Results

Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA

Step 1 — Preparing Subordinate Issuing CA

Step 2 — Installing AD CS role on Subordinate Issuing CA

Step 3 — Completing Subordinate Issuing CA installation

Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA

Step 1 — Preparing to install

Step 2 — Installing AD CS role on Offline Root CA

Step 3 — Finalizing Offline Root CA installation

Step 4 — Understanding post-installation script

Устанавливаем Certification Authority (часть 1) — Введение

Prologue

PKI tasks

Planning CA hierarchy

Planning CA types

Planning validity periods

Planning CDP/AIA extensions

Conclusion

Планирование расширений CDP и AIA

Рекомендация 1 — CA и IIS

Рекомендация 2 — CDP/AIA и LDAP

Отсебятина 1 — именование файлов

Рекомендация 3 — публикация файлов на Web-сервер

CDP — новая инсталляция

CDP — унаследованная инсталляция

AIA — новая и унаследованная инсталляции