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

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

[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

Примечание: конфигурационный файл должен обязательно называться 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 выберите Standalone. Поскольку компьютер не является членом домена, Enteprise нам недоступен. Нажмите Next.
6. На странице выбора типа CA выберите Root 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 Root Certification Authority.
   
   в поле Distinguished name suffix укажите примерно такое:
   
   OU=Information Systems,O={Adatum Ltd.},C={LV}
   
   и нажмите Next.
10. На странице Validity Period укажите срок действия сертификата. В большинстве случаев 10 лет — наиболее оптимальный срок действия корневого сертификата. Нажмите Next.
11. На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
12. На странице 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-х составляющих:

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

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

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

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

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

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

• CRL Publishing Properties
• AIA Publishing Properties
• CRL Distribution Point Replacement Token

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

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

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

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