Update 03.04.2010: добавлен OID для PolicyStatementExtension.
Update 26.06.2011: добавлена публикация корневого сертификата в Active Directory.
Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf. Обязательно прочтите.
Ссылки на другие материалы из этой серии:
В предыдущей части мы подготовили, установили и настроили наш первый корневой центр сертификации. Теперь настала пора подготовить, установить и настроить издающий центр сертификации, называемый 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 к успешной работе. Но об этом в следующий раз.
(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)