Наконец-то этот день настал и я получил очередное письмо:

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. Обязательно прочтите.

Ссылки на другие материалы из этой серии:

• Устанавливаем 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…)

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…)

Update 11.11.2010: Windows Server 2008 R2 Standard не поддерживает роль OCSP Responder.

Ссылки на другие материалы из этой серии:

• Устанавливаем Certification Authority — Подведение итогов

Prologue

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается. К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> ????? –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI. Вот один из примеров: Помогите установить и настроить службу сертификации. Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка PKI кажется задачей не сложнее администрирования нотепада и укладывается по времени в промежуток обеденного перерыва. При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI (Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC. Я не претендую на попытку устранить этот пробел, поскольку это нереально, но стараюсь дать какие-то полезные понятия и какие-то другие вещи в соответствии с бест-практисами.

PKI tasks

Во-первых, нужно определиться с задачами, которые могут потребовать внедрения PKI:

• Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN;
• Внедрение защищённых сетевых протоколов — L2TP, SSL, IPsec;
• Внедрение защищённой почты с шифрованием и/или подписью писем;
• Внедрение цифровых подписей документов и файлов, что гарантирует их целостность и альтернативу ручной подписи.
• Внедрение защищённых файловых хранилищ с шифрованием особо конфиденциальной информации.

Если из всего вышеперечисленного вам не нужно, PKI вам не нужна так же.

Planning CA hierarchy

В одном из своих предыдущих постов я вёл дискуссию об иерархиях PKI: Обсуждение схем иерархии Certification Authority. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии. Двухуровневая иерархия выглядит крайне привлекательно:

В принципе, если сеть достаточно сконцентрирована, такая схема будет идеальной для многих случаев. А если сеть географически распределена с крупными филиалами (сайтами), в каждый такой филиал можно добавить по ещё одному сертификату CA и получить вот такую схему:

Создание 3-х уровневой иерархии уже будет подразумевать разделение иерерхии на области действий CPS (Certificate Practice Statement) и будут подвержены различным политикам управления серверами CA. Это достаточно долгая песня и о ней говорить не будем. Поэтому мы остановимся на двухуровневой иерархии с одним корневым центром сертификации (Root CA) и одним издающим центром сертификации (Issuing CA).

Planning CA types

Microsoft поддерживает два типа центров сертификации — Standalone и Enterprise. Обычно администраторы привыкли устанавливать Enterprise CA и по очевидным причинам не используют Standalone CA. Чем они отличаются?

• Standalone

Характеризуются нетребовательностью к наличию домена Active Directory. Так же Standalone CA не использует шаблоны, следовательно вы не можете запрашивать сертификаты на таком CA через оснастку Certificates консоли MMC. Что означает, что вы не можете пользоваться функциями autoenrollment'а. Так же при выдаче сертификатов, Standalone CA не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера. Энролить сертификаты в Standalone CA можно только через Enrollment Web Pages, либо вручную генерируя запросы (файлы с расширением .req) и отправляя их через оснастку CertSrv.msc. Причём отправка запросов через оснастку CertSrv.msc является новой возможностью в Windows Server 2008. В связи с этим необходимость в Enrollment Web Pages отпала совсем.

По своим возможностям Standalone CA выглядит убогим чуть более, чем полностью. Но этот тип CA имеет одно сильное преимущество — он не зависит от наличия домена. Кажется — фигня. Домены даже рулят и педалят и всё, что работает без домена не нужно! Но давайте посмотрим на ситуацию немного с другой стороны. Центры сертификации верхних уровней (корневые и подчинённые центры сертификации первого уровня) имеют как правило очень большой срок действия — от 10 до 20 лет. При этом очень часто домены и леса AD живут значительно меньше, поскольку они постоянно реструктуирутся, переименовываются, мигрируются и т.д. А центр сертификации в домене (Enteprprise CA) лишает нас некоторых возможностей, как переименование домена и усложняют процессы реструктуризации доменов и лесов. По этой причине, Enterprise CA имеет небольшой срок действия своих сертификатов — от 5 до 10 лет максимум. В принципе, если есть независимый от домена AD центр сертификации (Standalone CA в рабочей группе) гораздо проще проводить миграцию и реструризацию лесов AD, поскольку эти процессы не затрагивают корневой CA и избавляют от проблем построения новой иерархии PKI. В такой ситуации достаточно только сменить центры сертификации 2-го и 3-го уровней (последний обычно является Enterprise CA). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

• Enterprise

Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на Standalone CA по своим возможностям. Во-первых Enterprise CA требует наличия домена для хранения там своей информации и шаблонов сертификатов. Данный тип CA имеет очень большие возможности по выдаче и обслуживанию сертификатов. Enterprise CA не требует генерации файлов запросов со стороны клиентов, а позволяет подавать заявки на сертификаты через оснастку Certificates консоли MMC и автоматически распространять сертификаты в масштабах целого леса AD при минимальном участии конечного пользователя. Чаще всего это участие сводится к настройке администратором политик autoenrollment'а и всё. Плюс, Enterprise CA может публиковать сертификаты в свойства учётных записей пользователей и компьютеров.

Однако, зависимость от домена вносит некоторые ограничения в свою жизнь. Поскольку домены достаточно подвижные единицы и подвержены изменениям, Enterprise CA имеют достаточно короткий срок действия своих сертификатов — от 5 до 10 лет максимум. В случае Enterprise Root CA, удаление домена автоматически ведёт к краху всей иерархии PKI и её придётся строить с нуля, что может вылиться в большие трудности в довесок к текущим проблемам удаления домена. Именно поэтому компании никогда не устанавливают корневой центр сертификации на Enterprise CA, а только Issuing CA, которые уже издают сертификаты конечным потребителям, где и восстребованы все возможности Enterprise CA. Хотя, в очень небольших компаниях этого будет вполне достаточно, когда корневой CA устанавливается на Enterprise CA и имеет срок действия сертификата 5 лет.

В данном цикле статей мы будем использовать преимущества обоих типов CA. Для корневого CA будем использовать Standalone CA в рабочей группе и для издающего CA будем использовать Enterprise CA в домене Active Directory. При этом Standalone CA не будет издавать сертификаты конечным потребителям, а только для других центров сертификации.

Planning validity periods

На какой срок будем выдавать сертификаты для каждого типа CA? 20 лет мне кажется слишком круто, ведь через 20 лет в вашей компании может всё круто поменяться и если ваш бизнес не завязан на предоставлении услуг цифровых сертификатов, 20 лет, наверное, слишком большой срок. А вот 10 лет для корневого и издающего будет вполне достаточно. Не надо думать, что через 10 лет всё умрёт. Просто через 10 лет (фактически чуть раньше, через 8-9 лет) вам придётся обновить сертификаты обоих CA и всё, жизнь будет продолжаться дальше. Издержки на обновлении сертификатов CA минимальные, поскольку никаких изменений в конфигурации производить не придётся.

Planning CDP/AIA extensions

Об этом у меня написано уже достаточно много:

• CRL Distribution Points и Authority Information Access
• Certificate chaining engine (CCE) и отзыв корневых сертификатов
• Планирование расширений CDP и AIA

Исходя из описанного по ссылкам (читать обязательно!) мы полностью откажемся от LDAP-ссылок и в сертификатах будем публиковать только ссылки на HTTP. Для этой цели нам потребуется веб-сервер, который будет хранить наши CRL/CRT файлы и поддерживать работоспособность ссылок. Поскольку корневой CA не будет издавать сертификаты конечным потребителям, а только для других CA, риск компрометации которых невелик (но всё же существует) и он большую часть времени будет выключен, мы отключим публикацию Delta CRL для корневого CA, но включим для Issuing CA. Основной CRL (Base CRL) мы будем публиковать каждые 3 месяца для корневого сертификата и каждые 5 дней для Issuing CA. Для обеспечения более быстрой реакции на отзыв сертификатов, для Issuing CA будем публиковать Delta CRL каждые 12 часов.

Так же можно предусмотреть использование OCSP (Online Certificate Status Protocol). Хоть обычно OCSP и используется только для Enterprise CA, ничего не мешает использовать его для корневого CA. С учётом роста количества клиентов под управлением Windows Vista и выше, это будет хороший экспериенс и я расскажу, как это можно будет реализовать.

Conclusion

Исходя из вышесказанного мы можем сформулировать программные требования для нашей иерархии PKI:

1. Windows Server 2008/2008 R2 Standard Edition.
   Компьютер является членом рабочей группы WORKGROUP, с именем хоста RootCA. Компьютер не подключен к локальной сети или к интернетам. В принципе, для это задачи можно использовать и Enterprise/Datacenter редакции, но от них вы никакого профита не получите в случае использования роли ADCS (Active Directory Certificate Services). Редакции Standard хватит вполне.
2. Windows Server 2008 Enterprise/Datacenter или Windows Server 2008 R2 Standard/Enterprise/Datacenter.
   Компьютер является членом домена Adatum.com с именем хоста Issuing CA. Компьютер не должен держать роль контроллера домена.
3. Домен Adatum.com содержит выделенный веб-сервер под управлением любой ОС и который доступен из интернета (только для обслуживания внешних клиентов).
4. Домен Adatum.com содержит сервер способный выполнять роль OCSP Responder'а. Если это будет Windows Server, требования к версии будут такие же, как и для Enterprise CA. Т.е. Windows Server 2008 R2 Standard/Enterprise/Datacenter или Windows Server 2008 Enterprise/Datacenter.

На этом я заканчиваю вводную часть и в следующих частях мы поговорим уже о непосредственной установке и конфигурировании центров сертификаций.

Примечание: для успешного освоения данного материала, необходимо прочитать мою предыдущую запись по теме: Встречаем – AppLocker!

Я в своё время написал пост о порядке сортировки правил в Software Restriction Policies (Секреты Software Restriction Policies (часть 4)). Некоторые вопросы в интернетах говорят мне о том, что с AppLocker'ом люди не особо разобрались и сильно путаются. Виной тому — полное отсутствие вменяемой документации по вопросам практической реализации и отсутствие серого вещества у некоторых администраторов. Сегодня я покажу как AppLocker выявляет результирующий статус для запускаемого приложения/скрипта.

В Software Restriction Policies правила достаточно простые, хотя и со своими тараканами. Например, у нас есть возможность использовать один из двух уровней по умолчанию — Disallowed и Unrestricted. Правила в SRP так же могут быть определены одним из двух уровней (на самом деле в SRP ещё есть Basic User, но я его опускаю, как незначительный момент). Т.е. правило либо однозначно запрещает, либо однозначно разрешает вне зависимости от уровня по умолчанию. А результирующий уровень определялся нехитрым методом сортировок правил.

С AppLocker'ом ситуация немного иная. Теперь уровень по умолчанию только Disallowed. Т.е. запрещено всё, что не разрешено. Вроде бы и просто, но сами правила стали немного сложнее — появились исключения. В результате этих исключений значительно усложнилась и изменилась методика определения результирующего уровня для запускаемого файла.

Примечание: под «файлом» я здесь подразумеваю файл с расширением, контролируемым в AppLocker'е.

Итак, AppLocker позволяет создавать правила с уровнем Deny или Allow. Каждое правило пути или издателя (Publisher), кроме правила хешей, могут содержать исключения. Поскольку правило издателя не может уникально идентифицировать конкретный файл, т.к. поле Subject сертификата достаточно абстрактное понятие и под одно такое правило может подпадать сотни различных файлов. Причём, ситуация усугубляется тем, что в Software Restriction Policies в правило сертификата указывался конкретный сертификат подписи, AppLocker их просто перестаёт различать! Т.е. область действия правила издателя становится ещё шире, чем с классическими правилами сертификатов в SRP. То же самое и с правилами пути, поскольку по указанному пути сегодня может быть один файл, а завтра уже другой. Но для AppLocker'а это будет всё один файл. А ещё могут быть ситуации, когда по некоторому пути нужно разрешить всё, кроме какого-то набора файлов. Недостатки (и достоинства одновременно) компенсируются наличием в правилах исключений. Исключения позволяют значительно сократить количество правил в AppLocker'е.

Примечание: Единственный способ уникальной идентификации файла в AppLocker'е (равно как и в SRP) может быть только правило хеша, поскольку хеш условно говоря уникально идентифицирует файл (в пределах коллизий хеша). Именно по этой причине правило хеша не поддерживает возможность использования исключений.

Основной сценарий, который многих сбивает с толку: создаём запрещающее правило по правилу издателя или правилу пути. Однако определённые файлы, подпадающие под этот запрет должны быть разрешены для запуска. Для этих целей мы можем смело воспользоваться исключениями. Поэтому мы вносим такие файлы в исключения по пути, хешу или издателю. И, казалось бы, исключение из запрета означает явное разрешение. На первый взгляд это так и есть. Однако, следует помнить, что AppLocker использует неотключаемое действие по умолчанию — Disallowed. И когда файл выпадает из явного запрета, он не разрешается автоматически, поскольку подпадает под действие по умолчанию, если нет явного разрешения. Вот такие пирожки. Следовательно, можно вывести общий постулат AppLocker'а: разрешённый файл не должен быть явно запрещён и должен быть явно разрешён. Этот постулат будет доказан и продемонстрирован чуть ниже.

Если SRP использовал сортировку правил по их типу, устанавливая заданный приоритет для каждого вида, AppLocker более не использует такой метод. Запрет по правилу пути не может быть перекрыт даже разрешением по хешу или правилу издателя, как это работает в SRP. AppLocker сортирует правила по их действию — Deny и Allow. Запреты отрабатываются в первую очередь и затем разрешения. Опираясь на мои исследования я составил примерно такой алгоритм работы правил аплокера:

• Сначала проверяются все явные запреты (в произвольном порядке).
  • Если файл подпал под явный запрет, то для этого запрета отрабатываются все исключения. Если файл всё ещё подпадает под явный запрет, то файл помещается в список «Denied» и блокируется для запуска. Остальные шаги проверки не производятся.
  • Если после обработки исключений больше не подпадает под явный запрет, то берётся следующее запрещающее правило и так продолжается, пока не будут проверены все явные запреты.
  • Если после отработки всех запретов, файл больше не подпадает под явный запрет, он помещается в список «Processing».
• Если файл находится в списке «Processing», файл проходит через второй этап проверки. Если список «Processing» пуст, файл не проходит через второй этап и хмуро блокируется для запуска.
• Если файл подпал под явное разрешение, то для этого разрешения отрабатываются все исключения. Если файл всё ещё подпадает под разрешение, файл помещается в список «Allowed» и разрешается для запуска. Остальные шаги проверки не производятся.
• Если после обработки исключений файл больше не подпадает под явное разрешение, то берётся следующее разрешающее правило, и процесс повторяется для каждого разрешающего правила.
• Если после отработки всех разрешений, файл всё ещё находится в списке «Processing», к файлу применяется действие по умолчанию. Т.е. файл блокируется для запуска.

Примечание: на самом деле никаких таких списков не существует, это я всё соврал. Я их придумал только для улучшения понимания.

Для наглядной демонстрации алгоритма я нарисовал следующую картинку:

Ну и в качестве бонуса — практическая задача, которая продемонстрирует этот алгоритм в действии.

Задача:

На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе «Accountants» необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из «Program Files» разрешён без ограничений.

Решение:

Для решения этой задачи мы должны разрешить весь каталог «Program Files» по правилу пути для группы «Everyone». Поскольку доступ к программам Microsoft Office будет ограничен только для группы «Accountants», мы создаём новое запрещающее правило (с действием «Deny»), которое применяется только к группе «Accountants». Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы «Accountants». Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов «Excel.exe» и «Winword.exe».

Проверка:

Исходя из диаграммы, посмотрим, что будет происходить, когда член группы Accountants запустит PowerPNT.exe (PowerPoint).

При запуске мы попадаем на первый условный переход: подпадает ли файл под какой-нибудь запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно выходим на следующий условный переход: указан ли PowerPNT.exe в исключениях? Правило запрета не предусматривает исключения для этого файла, следовательно мы выходим на действие «File is blocked to run». При этом алгоритм заканчивается.

А теперь член группы Accountants запускает Excel.exe (Excel). При запуске мы снова попадаем на первый условный переход: подпадает ли файл под запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно переходим на следующий условный переход: указан ли Excel.exe в исключениях данного правила? Да, указан в исключениях, поэтому переходим на третий условный переход: есть ли ещё запрещающие правила? Если нет, мы сразу попадаем на четвёртый условный переход, который уже отрабатывает разрешения. Если есть ещё запрещающие правила, в них Excel.exe никак не запрещается (по условию задачи это не подразумевается), мы прямиком с первого условного перехода попадаем на четвёртый условный переход: подпадает ли файл хоть под одно разрешающее правило? Да, файл подпадает под разрешающее правило всего каталога Program Files для группы Everyone, в которую входит и группа Accountants. В результате попадаем на пятый условный переход: есть ли исключение для Excel.exe в этом разрешающем правиле? Нет, исключений для правила не предусмотрено и мы выходим на действие «File is allowed to run».

Как видите, используя эту диаграмму, можно разбирать правила любой сложности в пошаговом режиме и теперь вы знаете, как сортируются и проверяются правила AppLocker'а.

Напоследок ещё хочется отметить ситуацию применения множественных политик. Так же как и в случае с Software Restriction Policies, правила никак не замещаются, а суммируются. Т.е. собираются в один список, после чего AppLocker оперирует правилами, собранных со всех политик, применённых к конкретному компьютеру.

Что бы почитать?

• Встречаем – AppLocker!
• Секреты Software Restriction Policies (часть 4)