Posts on this page:
- Устанавливаем Certification Authority — Подведение итогов
- Устанавливаем Certification Authority (часть 4) — Конфигурирование Subordinate Issuing CA
- MVP: PowerShell — дубль номер следующий
- Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA
- Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA
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…)
Наконец-то этот день настал и я получил очередное письмо:
Dear Vadims Podans,
Congratulations! We are pleased to present you with the 2010 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in PowerShell technical communities during the past year.
В принципе, ожидаемое событие, но всё равно негарантированное и это прекрасно! В целом, наверное, заслуженно, хотя во второй половине прошлого года акцент бложика и моей активности стал заметно уходить от пошика в сторону секурити. А в этом году про PowerShell не написал ещё ни одного поста. Вроде не надоел, просто я достиг того максимума который мне необходим и который для меня достижим. Поскольку дальше тематика скатывается к программированию, от которого я слишком далёк. Учитывая эти тенденции, это последний авард в рамках специализации PowerShell. Что будет дальше — посмотрим. В принципе, я уже более-менее определился с курсом, но чёрт его знает, может, опять шатнёт в какуб-нибудь экспертизу :-)
К слову говоря, наших местных (латвийских) MVP стало чуть меньше. Т.е. не 4, как это было год назад, а уже 3:
- Andrejs Mamontovs – ASP/ASP.NET
- Valdis Iļjučonoks - Visual C#
- Vadims Podāns – PowerShell
Вобщем, на этом пока всё. Будем продолжать работать в каком-то направлении, а через год узнаем, что из этого вышло.
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…)
Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf и пост-конфигурационном скрипте. Обязательно прочтите.
Ссылки на другие материалы из этой серии:
В первой части установки 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 укажите название вашей компании. Места, в которых необходимо прописать свои данные заключены в фигурные скобки — {}.
- На странице 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 |
2 |
| Include in the CDP extension of issued certificates. | 2 |
Include in the Online Certificate Status |
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 и что-нибудь ещё.
Файлы для скачивания:
(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)