Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в постустановочном скрипте
Ссылки на другие материалы из этой серии:
В предыдущей части (Устанавливаем 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. И вот что вы должны увидеть в конечном итоге:
Results
Для окончательной проверки мы можем запустить оснастку PKIView.msc. Если мы настроили всё правильно, то должны увидеть примерно такой вид:
И подведём итоги того, что мы сделали:
- Мы спланировали типовую 2-х уровневую иерархию и конфигурацию PKI, которая включает в себя Offline Root CA и Online Issuing CA;
- Установили и сконфигурировали соответствующим образом наш корневой Root CA, который может быть нормально выключен и который будет издавать сертификаты только для других центров сертификации;
- Установили и сконфигурировали подчинённый Issuing CA, который будет издавать сертификаты уже конечным потребителям.
- Настроили OCSP Responder для работы с Offline Root CA.
Вроде бы выглядит немного, но исходя из материала мы проделали достаточно большой объём работы, в результате мы получили достаточно гибку и, главное, работающую PKI.
(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)