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 укажите название вашей компании. Места, в которых необходимо прописать свои данные заключены в фигурные скобки — {}.

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

Step 3 — Completing Subordinate Issuing CA installation

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

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

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

1. Скопируйте файлы со съёмного носителя (содержимое папки CertData, которое вы скопировали на предыдущем этапе) на локальный диск. Например, в ту же папку C:\CertData.
2. Запустите консоль 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, он не сможет проверить на отзыв свой собственный сертификат.
3. Убедитесь, что ошибок не произошло. Если это так, закройте консоль CMD.

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

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

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