Установка цепочки серверов сертификации как часть внедрения PKI в домене Часть 3

Станислав Шпак

Установка цепочки серверов сертификации
как часть внедрения PKI в домене
Часть 3

В первых двух частях статьи [1, 2] мы рассматривали процесс установки и настройки цепочки из трех серверов, которые будут составлять ядро структуры PKI в вашем домене. Осталось только произвести некоторые настройки в домене, чтобы вся конструкция перестала быть бесполезным железом и наконец заработала.

В отличие от изолированных СА (Certificate Authority) СА уровня предприятия обычно настраиваются на автоматический выпуск сертификатов. При этом для заполнения нужных полей сертификата информация берется из Active Directory. Разумеется, сертификаты для более важных целей (например, смарт-карты) можно выпускать вручную – такой метод дает возможность более строго контролировать процесс сертификации.

СА использует шаблоны сертификатов для автоматизации формирования сертификатов из запросов. Windows Server 2003 Enterprise Edition (и Datacenter Edition) поддерживают шаблоны второй версии (V2), в то время как более ранние ОС – только первой (V1). Основное различие между версиями в том, что шаблоны V1 предопределены и неизменяемы, в то время как шаблоны V2 позволяют сконфигурировать множество опций, которые будут применены к сертификату в процессе его выпуска.

Шаблоны сертификатов хранятся в Active Directory, поэтому, сконфигурировав шаблон на одном СА, вы будете иметь доступ к этому шаблону на любом другом СА в лесу. Это означает также и то, что, удалив шаблон, вы удалите его из Active Directory, и он не будет больше доступен нигде.

Для использования шаблонов V2 в смешанной доменной среде требуются расширение схемы AD до уровня 2003 Server и установка, как минимум, SP3 на контроллеры домена под управлением Windows 2000. Кроме того, использовать шаблоны V2 для запроса сертификатов могут не все клиенты – тут существуют разные ограничения в зависимости от метода запроса сертификата.

Таких методов несколько – сертификат может быть запрошен автоматически, через соответствующую оснастку MMC, посредством Web или через скрипт из командной строки. Позже рассмотрим некоторые из них. Имейте также в виду, что если в домене существуют несколько выпускающих СА, то запрос сертификата от клиента может быть направлен на любой доступный СА, причем этот СА необязательно будет ближайшим. Это стоит учесть, располагая СА в домене.

Автоматический выпуск сертификатов настраивается как комбинация доменных политик и шаблонов сертификатов. В результате выпуск сертификатов может стать для пользователя абсолютно прозрачным. Кроме того, это снижает стоимость администрирования всей структуры PKI.

Те шаблоны сертификатов, по которым СА может выдавать сертификаты после установки, можно посмотреть в оснастке Certification Authority (центр сертификации) в разделе Certificate Templates (шаблоны сертификатов). Если нажать в этом разделе правую кнопку мыши и выбрать пункт Manage (управление), то запустится оснастка Certificate Templates (шаблоны сертификатов), с помощью которой можно управлять шаблонами сертификатов (см. рис. 1). Эти две оснастки тесно связаны, поэтому уделим им чуть больше внимания.

Рисунок 1. Оснастка Certifacate Templates

 Итак, что нужно знать:

•  Шаблоны V2 помечены в списке цветной иконкой, в то время как шаблоны V1 – черно-белой.
•  Повторюсь: параметры шаблонов V2 менять можно, V1 – нет.
•  Очень не рекомендуется удалять шаблоны.
•  Если нужно исправить шаблон, лучше создать его копию (щелкнув правой кнопкой мыши на имени шаблона и выбрав из меню Dublicate Template (скопировать шаблон).
• Для использования в СА становятся доступны те шаблоны, в свойствах которых на вкладке General (общие) отмечена опция Publish in Active Directory (опубликовать сертификат в Active Directory).
• Даже если шаблон доступен для СА, чтобы пользователи могли с ним работать, надо настроить права на вкладке Security (безопасность).
• Если вы используете доменную структуру с корневым доменом, обратите внимание, что по умолчанию права для использования шаблона обычно даются учетным записям из корневого домена. Для учетных записей из нижележащих доменов эти права надо дать явным образом.
• Чтобы добавить шаблон в список шаблонов, обрабатываемых СА, надо в оснастке Certification Autority в разделе Certification Templates нажать правую кнопку мыши и выбрать «New -> Certificate Template to Issue» («Создать -> Выдаваемый шаблон сертификата»), после чего выбрать из списка шаблона нужный.
• Если вы создали копию шаблона, настроили его свойства, не забыли отметить опцию Publish in Active Directory, а этот шаблон не появился в списке доступных для СА шаблонов, подождите немного.
• В тех шаблонах, которые предназначены для выпуска сертификатов с целью шифрования данных, иногда имеет смысл включить опцию Archive subject’s encryption private key (архивировать закрытый ключ субъекта) на вкладке Request Handling (обработка запроса) – это может помочь в будущем в случае необходимости восстановления данных, зашифрованных этим сертификатом.
• Если надо включить в шаблоне какую-то опцию, а это сделать нельзя ввиду того, что шаблон относится к версии 1, создайте дубликат шаблона (но помните, что не все клиенты умеют работать с шаблонами V2).

Итак, теперь проведем первичную настройку шаблонов. Нам потребуются, как минимум, шаблоны типа Domain Controller (контроллер домена), Computer (компьютер) и User (пользователь). Все эти шаблоны уже перечислены в разделе Certificate Templates оснастки Certificate Authority, так что нам остается только проверить, есть ли у пользователей необходимые права на использование этих шаблонов. Для этого в оснастке Certificate Templates нужно найти каждый из этих шаблонов и, заглянув в свойства, проверить установки на вкладке Security. Поскольку в нашей тестовой среде мы использовали двухуровневую доменную структуру с корневым доменом [1], то разрешения для шаблонов установлены только для учетных записей из домена Dedicated.Root. Нам необходимо в соответствующие шаблоны добавить право Enroll (Заявка) для учетных записей домена Res.Dom. Если у вас учетные записи пользователей и компьютеров будут располагаться в том же домене, что и выпускающий СА, то никаких дополнительных настроек безопасности не потребуется.

Как уже говорилось в предыдущей части статьи, в домене Windows 2000 происходил автоматический запрос сертификатов контроллерами домена, как только появлялся СА уровня предприятия. В домене Windows 2003 этого нет, поэтому начнем с настройки автоматического запроса сертификатов контроллерами домена.

Для этого надо открыть групповую политику контроллеров домена (обычно это Default Domain Controller Policy) и перейти в ветку «Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Automatic Certificate Request» («Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Политики открытого ключа -> Параметры автоматического запроса сертификатов»). Здесь надо нажать правую кнопку мыши и выбрать «New -> Automatic Certificate Request» («Создать -> Автоматический запрос сертификата»), в результате чего запустится несложный мастер, в котором нужно указать, автоматический выпуск каких типов сертификатов мы хотим настроить. Поскольку эта политика применяется только к контроллерам домена, то и выбираем из предложенного списка Domain Controller (см. рис. 2).

Рисунок 2. Выбор шаблона сертификата

После этого из командной строки запускаем команду «gpupdate /force» для применения групповой политики и проверяем, что контроллер домена получил сертификат. Для этого открываем системный журнал событий в разделе Applications (программы), где мы должны увидеть информационное событие от источника AutoEnrollment с ID 19 примерно следующего содержания:

Это говорит о том, что сертификат успешно получен. Если же в групповых политиках будет включено автоматическое получение сертификата, а в шаблоне на вкладке Security не будут даны права на использование этого шаблона, то в журнале событий можно будет увидеть следующее:

Аналогичным образом можно произвести настройку доменной политики для автоматической выдачи сертификатов компьютерам домена и, если необходимо, пользователям. Обратите внимание на настройку Autoenrollment setting (параметры автоматической подачи заявок) в ветке «Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies». Она позволяет указывать, нужен ли автоматический выпуск сертификатов и если да, то каким образом проводить обновление сертификатов по истечении срока их действия (см. рис. 3).

Рисунок 3. Параметры автоматической подачи заявок

Если по каким-то причинам автоматический выпуск сертификатов недоступен (например, нужно выпустить сертификат для компьютера, который не является членом домена), то можно воспользоваться одним из способов, из перечисленных ранее. Например, через браузер (рекомендуется Internet Explorer версии 5.01, но вообще чем новее, тем лучше).

Примечание: для того чтобы воспользоваться возможностью веб-запроса сертификата через браузер из ОС Windows Vista, потребуется применить дополнительный патч для выпускающего СА [3].

Итак, запускаем браузер и открываем страницу http://EntCA/certsrv (где EntCA – имя нашего СА). Мы попадаем на стартовую страницу сервера сертификатов, с которой можно пойти по трем ссылкам:

• Request a certificate – запросить сертификат;
• View the status of a pending certificate request – посмотреть статус запрошенного сертификата;
• Download a CA certificate, certificate chain, or CRL – скачать сертификат СА, цепочку из сертификатов вышестоящих СА или CRL.

В нашем случае нажимаем Request a certificate и попадаем на следующую страницу, где нужно либо выбрать тип сертификата, либо перейти к подробному формированию запроса по ссылке Аdvanced certificate request. Нажав на нее, мы переходим к трем опциям, из которых нас интересует первая – Create and submit a request to this CA. Нажав на ссылку, можно выбрать нужный тип сертификата (в списке представлены только те шаблоны, для использования которых у пользователя достаточно прав) и ряд дополнительных параметров (которые меняются в зависимости от выбранного шаблона) (см. рис. 4). Нажав на кнопку Submit внизу страницы, мы отправляем запрос на выдачу сертификата на СА. Если на СА для данного шаблона настроен автоматический выпуск сертификата, то ссылку на скачивание и установку сертификата вы увидите уже на следующем шаге. Иначе вам нужно будет вручную выпустить сертификат посредством оснастки Certification Authority и затем либо экспортировать его из оснастки, либо воспользоваться браузером.

Рисунок 4. Запрос сертификата через браузер

Когда вы устанавливаете сертификат на компьютер, который не является членом домена, то нужно не забыть, что вам еще потребуется установить сертификат СА в хранилище доверенных корневых сертификатов. Получить сертификат СА можно или через веб-запрос (по ссылке Download a CA certificate, certificate chain, or CRL), или взять из точки распространения сертификатов, доступной клиентам (обычно это то же самое место, куда публикуются CRL из СА предприятия).

Очень важно, чтобы внешние клиенты могли получить доступ к сертификату вашего корневого СА, поэтому не пренебрегайте возможностью размещения файлов CRL и файла сертификата корневого СА в местах, доступных извне (например, на веб-сайте). Имея сертификат корневого СА (в нашем случае это файл RootCA_RootCA.crt), нужно открыть оснастку Certificates (не важно, для пользователя или компьютера) и открыть ветку «Certificates -> Trusted Root Certification Authorities -> Certificates» («Сертификаты -> Доверенные корневые центры сертификации -> Сертификаты»). Нажать правую кнопку мыши, выбрать All Tasks v Import («Все задачи -> Импорт») и далее, следуя указаниям мастера, импортировать сертификат в хранилище (на втором шаге лучше указать хранилище в явном виде, не позволяя мастеру выбрать его автоматически).

Заключение

Теперь, когда мы получили работающую цепочку серверов сертификации, кратко перечислю основные моменты процесса:

• Для установки корневого СА используйте файл capolicy.inf, в котором разделы указания CDP и AIA надо оставить пустыми.
• Изолированные СА держите физически выключенными до тех пор, пока не потребуется обновить файл CRL или сертификат СА.
• Тщательно выбирайте интервалы публикации списков отзыва сертификатов.
• При обновлении CRL или сертификата изолированного СА не забывайте импортировать измененные данные в AD. Только СА уровня предприятия делают это автоматически.
• Следите за тем, чтобы в точках CDP всегда лежали актуальные CRL-файлы, а сами точки CDP были доступны.
• Поместите сертификат корневого СА в такое место, где он будет легко доступен как для внешних, так и для внутренних клиентов.
• Делайте резервное копирование СА. Для этого можно использовать команду certutil.exe, но только использование программы ntbackup с опцией System state позволяет создать резервную копию всей связанной с СА информации.

1. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 1. //Системный администратор, №8, 2008 г. – С. 54-58.
2. Шпак С. Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 2. //Системный администратор, №10, 2008 г. – С. 60-64.
3. http://support.microsoft.com/kb/922706.
4. Windows Server 2003 PKI Operations Guide – http://technet.microsoft.com/en-us/library/cc787594.aspx.