Инфраструктура PKI и службы сертификатов в Windows Server 2003
Работа с корпоративными и автономными центрами сертификации CA
Центр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), является ключевым компонентом программного обеспечения инфраструктуры открытых ключей PKI (Public Pey Infrastructure) в среде Windows Server 2003. Центр CA принимает и обрабатывает запросы на получение сертификатов от пользователей PKI, идентифицирует эти запросы и проверяет их правомерность, выдает сертификаты в соответствии с политикой безопасности PKI, обновляет и аннулирует сертификаты, размещает сертификаты на различных узлах хранения, создает и публикует списки аннулированных сертификатов CRL (Сertificate Revocation Lists), а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL.
Центр сертификации Windows 2003 CA может выполнять в безопасном режиме архивирование и восстановление секретных ключей. Чтобы оценить степень развития возможностей центров CA и PKI в среде Windows 2003, в этой статье мы рассмотрим компоненты архитектуры последней реализации служб Certificate Services, а также различия в процедурах развертывания корпоративного и автономного центра CA в среде Windows 2003.
Архитектура Windows 2003 Certificate Services.
Архитектура Windows 2003 Certificate Services почти идентична той, которая использовалась Microsoft при реализации предыдущих версий названных служб. Основное различие состоит в том, что здесь Microsoft изменила структуру базы данных CA для реализации поддержки процедур архивирования и восстановления секретных ключей пользователей. Схема данной архитектуры показана на рисунке. Она включает в себя различные модули, базы данных, инструментальные средства администрирования, посредников и прикладной интерфейс CryptoAPI.
Модули.
Сердцем Certificate Services является исполнительный механизм CA (certsrv.exe), который генерирует сертификаты и занимается управлением потоками сообщений между CA и другими компонентами служб Certificate Services. Серверный механизм CA взаимодействует с другими компонентами архитектуры через входные модули, модули политики и выходные модули.
Входной модуль принимает запросы на сертификаты, соответствующие формату криптографического стандарта открытых ключей № 10 (Public-Key Cryptography Standards, PKCS #10) или криптографического протокола управления, использующего синтаксис криптографических сообщений (Cryptographic Management protocol using Cryptographic Message Syntax, CMS). После приема запроса входной модуль помещает его в очередь для дальнейшей обработки модулем политики.
Модуль политики реализует правила политики центра CA в соответствии с установками, заданными администратором CA. Данный модуль передает исполнительному механизму CA информацию о структуре сертификата и принимает решение о выдаче сертификата, об отказе в его выдаче или о переводе запроса сертификата в режим ожидания. Для обновления информации о структуре сертификата модуль политики может обращаться к информации, хранящейся в каком-либо каталоге (например, Active Directory) либо в базе данных. Модуль политики, имеющийся в Windows 2003, называется certpdef.dll. Он поддерживает два типа политики: режим корпоративной политики и режим автономной политики. Эти режимы будут подробно рассмотрены ниже. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, следует запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Policy Module, показанной на экране 1.
Экран 1. Вкладка Policy Module в свойствах объекта
Выходные модули занимаются распространением и публикацией сертификатов, цепочек сертификатов, а также полных списков CRL и списков изменений CRL. Выходной модуль может записывать данные PKI в файл или передавать эти данные на удаленный узел, используя в качестве транспорта протокол HTTP или механизм удаленного вызова процедур RPC. Windows 2003 CA может поддерживать несколько выходных модулей, соответственно распространение и публикация сертификатов, цепочек сертификатов, полных cписков CRL и списков изменений CRL может выполняться одновременно в различные пункты назначения, включая каталоги LDAP, файловые ресурсы совместного пользования, каталоги Web и, наконец, ODBC-совместимые базы данных. По умолчанию в Windows 2003 CA входит выходной модуль, называемый certxds.dll, в котором реализована поддержка LDAP, FTP, HTTP и SMTP (в центрах Windows 2000 CA также поддерживаются все эти протоколы, за исключением последнего). Выходной модуль позволяет организовать автоматическую рассылку уведомлений от центра CA пользователям PKI и администраторам. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, нужно запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Exit Module, показанной на экране 2.
Экран 2. Вкладка Exit Module в свойствах объекта
Модули политики и выходные модули являются настраиваемыми и заменяемыми компонентами, поэтому любая организация может разработать на языках C++ или Visual Basic (VB) собственные модули и интегрировать их в архитектуру Certificate Services. Вся необходимая информация о процессах создания и замещения модулей имеется в комплекте документации Software Development Kit (SDK) для платформы Windows 2003.
Настройка модулей политики и выходных модулей осуществляется с помощью оснастки Certification Authority или через утилиту командной строки certutil.exe. Используя окно свойств объекта CA оснастки Certification Authority, можно добавлять выходные модули, настраивать расширения X.509 для сертификатов (например, определять узлы CDP (CRL Distribution Points) и узлы AIA (Authority Information Access)), а также настраивать параметры публикации для полных списков CRL и списков изменений CRL.
Базы данных.
Центр CA имеет собственную базу данных, которая называется CAname.edb. В этой базе хранится информация по транзакциям, связанным с сертификатами, и собственно сертификаты. Здесь же хранятся архивированные секретные ключи. По умолчанию эта база данных хранится в каталоге \%systemroot%\system32\certlog. Исполнительный механизм центра CA взаимодействует с базой данных с помощью файла certdb.dll. С появлением службы Windows 2000 Certificate Services изменилась используемая Microsoft технология работы с базами данных. Теперь здесь используется процессор баз данных Jet, что позволило сделать архитектуру Windows 2000 CA масштабируемой. Отметим, что аналогичная технология используется в базах данных AD и Microsoft Exchange Server.
Средства администрирования.
В большинстве случаев для администрирования центра сертификации Windows 2003 CA используется оснастка Certification Authority, но это можно делать и с помощью утилиты командной строки certutil.exe. Оба средства взаимодействуют с исполнительным механизмом центра CA через библиотеку certadm.dll.
Посредники (intermediaries).
Прикладные программы, помогающие клиенту корректно сформировать запрос сертификата, соответствующий формату PKCS #10 или CMS, называются посредниками или Registration Authorities (RA). Эти программы собирают специальные данные о пользователе и о запросе, которые необходимы для формирования корректного запроса сертификата. Например, любой запрос, направляемый корпоративному центру Windows 2003 CA, должен содержать ссылку на шаблон сертификата. Программы RA могут добавлять к запросу описание шаблона. Следует отметить, что эти программы используют определенные транспортные протоколы (например, HTTP и RPC), соответственно при этом и исполнительный механизм CA не должен использовать для работы другие типы транспорта.
Примерами посредников в Windows 2003 могут служить Web-страницы регистрации сертификатов, которые являются посредниками HTTP, а также оснастка Certificates консоли MMC, вызывающая мастер Certificate Request Wizard, которая играет роль RPC-посредника. При генерации секретных ключей на клиентской машине посредник HTTP обращается к библиотеке xenroll.dll, а при генерации секретных ключей на смарт-картах он использует библиотеку scenroll.dll. Посредник RPC для выполнения данных процедур вызывает библиотеку certcli.dll.
Прикладной интерфейс CryptoAPI.
Для реализации всех криптографических функций, включая доступ и использование секретных ключей CA, центр сертификации задействует вызовы интерфейса CryptoAPI. Центр CA может хранить свой секретный ключ на жестком диске или на специальном аппаратном устройстве (например, на аппаратном модуле безопасности Hardware Security Module, HSM).
Установка Windows 2003 Certificate Services
При выполнении установки Windows 2003 Certificate Services может быть развернут корневой CA, подчиненный CA, корпоративный CA (интегрированный в AD) или автономный CA (не интегрированный в AD). Если служба Certificate Services устанавливается в корпоративном режиме, то в этом случае активируется аналогичный режим и для модуля политики центра Windows 2003 CA. Рассмотрим, чем отличаются корпоративный и автономный режимы. В таблице приведены сравнительные характеристики параметров, установленных по умолчанию, для автономного и корпоративного центров Windows 2003 CA.
При установке корпоративного центра CA та учетная запись, от имени которой выполняется установка, должна иметь привилегии Enterprise administrator и Domain administrator в корневом домене леса AD. Кроме того, сервер, на который устанавливается корпоративный CA, должен являться членом домена с функционирующей в нем службой AD. Если эти условия не выполнены, в CA installation Wizard будут недоступны возможности перехода в режим установки enterprise CA, соответственно развернуть центр CA можно будет только в автономном режиме.
Для того чтобы установить автономный центр CA, использовать AD необязательно. CA может устанавливаться как на автономный сервер, так и на сервер, входящий в домен, или на контроллер домена (DC). При такой установке не требуются и полномочия Enterprise administrator и Domain administrator, вполне достаточно прав локального администратора на данном сервере. Если при установке автономного центра CA все-таки использовать привилегии Enterprise administrator, в этом случае данный центр будет обладать некоторой дополнительной функциональностью. В частности, если пользователь с правами Enterprise administrator устанавливает автономный центр CA на сервер, входящий в состав домена, то в этом случае центр CA сможет публиковать выпущенные им сертификаты в AD.
Шаблоны сертификатов
Корпоративный центр CA использует шаблоны сертификатов, которые хранятся в структуре AD в контексте имен конфигурации. Шаблон определяет содержание и характеристики сертификата. Кроме того, с помощью шаблонов можно контролировать типы выпускаемых центром CA сертификатов и определять, какие пользователи могут запрашивать сертификаты у корпоративного центра CA, а также сертификаты какого типа могут им выдаваться. В инфраструктуре PKI среды Windows 2003 поддерживаются шаблоны сертификатов версии 2, которые, в отличие от шаблонов версии 1, являются полностью настраиваемыми. Настройка шаблонов осуществляется с помощью оснастки Certificate Templates консоли MMC.
Автономный центр CA не может использовать шаблоны сертификатов AD, в этом случае нельзя выполнять контроль типов сертификатов и пользователей, их получающих. По умолчанию автономный CA может выдавать только сертификаты, предназначенные для Web-аутентификации (Secure Sockets Layer, SSL; или Transport Layer Security, TLS), защиты электронной почты (Secure MIME, S/MIME), аутентификации сервера, цифровой подписи и для работы с протоколом IP Security (IPSec). Тем не менее можно модифицировать Web-интерфейс автономного центра CA (например, для того чтобы в списке отображались другие типы сертификатов) или запрашивать другие типы сертификатов, используя для этого значения специальных идентификаторов объектов (OID), которые хранятся в X.509-расширении сертификата Extended Key Usage.
Получение дополнительной информации при запросе сертификата
В процессе регистрации сертификата корпоративный центр CA ищет в структуре Active Directory информацию о пользователе, которая потребуется центру для заполнения определенных полей сертификата. Например, в поле X.509 SubjectAltName сертификата, выданного корпоративным центром CA, содержится ссылка на имя пользователя, определяющее его в AD, — User Principal Name (UPN). Если центр CA является автономным, он не имеет доступа к AD, поэтому информация, идентифицирующая пользователя и необходимая для получения сертификата с Web-сайта регистрации, должна вводиться пользователем вручную.
Как в корпоративных, так и в автономных центрах CA можно изменять установленные по умолчанию параметры, добавляемые центром CA к запросу сертификата. Это делается в процессе регистрации сертификатов путем редактирования файла certdat.inc, который находится в каталоге \%systemroot%\system32\certsrv. Допускается изменение значений, установленных по умолчанию, для следующих параметров сертификата: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, и sDefaultCountry. Если привести значения этих параметров в соответствие с используемыми в организации наименованиями, можно будет сократить объем вводимой пользователем информации при запросе сертификата.
Автоматическая регистрация сертификатов
Центр CA корпоративного типа поддерживает технологию автоматической регистрации сертификатов, причем в Windows 2003 возможности данной технологии расширены и теперь распространяются как на пользовательские сертификаты, так и на сертификаты компьютеров. Отметим, что если пользователь запрашивает сертификат от автономного центра CA, процесс регистрации должен быть запущен вручную, так как в данном случае какие-либо процедуры автоматизации отсутствуют.
Централизованное архивирование ключей
Корпоративный центр CA поддерживает механизмы централизованного архивирования ключей в базе данных CA, а автономный центр — нет.
Утверждение запроса сертификата
В корпоративных центрах CA имеется поддержка механизмов автоматического и ручного утверждения запросов сертификатов. Для того чтобы настроить свойства режима обработки запросов сертификатов, можно воспользоваться либо свойствами корпоративного CA (через свойства модуля политики), либо свойствами шаблона сертификата версии 2 (с помощью вкладки Issuance Requirements окна свойств шаблона сертификата). Если настройка режима обработки запросов выполняется через свойства шаблона сертификата версии 2, то следует иметь в виду, что внесенные при этом изменения будут применены только к сертификатам того типа, который определяется данным шаблоном. Можно задать настройку, обязывающую администратора утверждать все поступающие запросы сертификатов вручную, независимо от установок в шаблоне сертификата. Для этого при настройке режима обработки запросов в свойствах CA нужно выбрать пункт Set the certificate request status to pending. The administrator must explicitly issue the certificate. Эти же пункты доступны и для автономного центра CA, с той лишь разницей, что автономный CA не может использовать шаблоны сертификатов, и, следовательно, не удастся настроить свойства обработки запросов для отдельного шаблона сертификата. В отличие от корпоративного центра, автономный CA при аутентификации поступающих запросов не использует внутренние механизмы аутентификации Windows, соответственно компания Microsoft не рекомендует устанавливать режим автоматического утверждения в свойствах обработки запросов для автономных центров CA. В этих случаях всегда следует оставлять установку, сделанную по умолчанию, в соответствии с которой каждый поступающий запрос сертификата должен утверждаться администратором вручную.
Опубликование сертификатов и списков CRL
Корпоративные центры CA хранят и публикуют сертификаты, а также полные списки CRL и списки изменений CRL в Active Directory. В то же время как корпоративные центры, так и автономные CA могут осуществлять размещение данных в файловой системе. Каждый размещенный в AD сертификат автоматически отображается на учетную запись того, кто его запрашивал. Служба Active Directory добавляет сертификат к многозначному атрибуту UserCertificate пользователя или объекта AD inetOrgPerson. Отметим, что не каждый выданный корпоративным центром CA сертификат автоматически публикуется в AD. Примерами сертификатов, которые не будут публиковаться автоматически, могут служить сертификат агента регистрации или сертификат для подписи списка CTL (certificate trust list).
В принципе автономный центр CA тоже может публиковать выпущенные им сертификаты в AD, но по умолчанию этот режим не поддерживается. Данная возможность может быть реализована только при развертывании автономного центра CA на сервере, который является членом домена. Отметим, что всегда можно явно размещать сертификаты в AD в ручном режиме.
Выбор типа CA, оптимального для решаемых задач
Итак, мы определили различия между корпоративным и автономным центром CA и теперь, на основании полученных знаний, можем выбирать конфигурацию центра CA, оптимальную для конкретной ситуации. Развертывание корпоративного центра Windows 2003 CA будет наилучшим решением для работы с сертификатами пользователей, имеющих учетные записи в AD и использующих протокол Kerberos для их аутентификации в инфраструктуре AD. Для внешних пользователей (например, пользователей из внешней сети, не имеющих учетных записей в инфраструктуре Windows внутренней сет) оптимальным решением будет использование автономного центра Windows 2003 СA.
Таблица. Сравнение основных характеристик автономного и корпоративного центров сертификатов Windows2003 CA
Свойство
Автономный Windows 2003 CA
Корпоративный Windows 2003 CA
Возможность интеграции в AD
По умолчанию отсутствует
Интегрированный в AD
Протоколы взаимодействия с CA
Клиенты взаимодействуют с CA по протоколам HTTP или HTTP Secure (HTTPS)
Взаимодействие клиентов с CA может осуществляться через RPC или Distributed COM DCOM), а также по протоколам HTTP или HTTPS
Распространение сертификатов
Центр CA загружает CA в пользовательский профиль, когда пользователь получает в ручном режиме сертификат с Web-сайта центра CA. Есть возможность автоматического размещения списков CRL и сертификатов в AD
В зависимости от настройки шаблона сертификата центр CA может автоматически загрузить сертификат в пользовательский профиль, поместить сертификат в AD либо выполнить оба действия
Утверждение запросов сертификатов
Процедура выдачи разрешений на регистрацию сертификатов может быть автоматической или ручной. Режим работы данной процедуры контролируется в центре CA с помощью одной общей настройки для всех типов сертификатов
Процедура выдачи разрешений на регистрацию может быть автоматической или ручной. Есть возможность как глобального контроля данного режима на уровне центра CA, так и задания различных режимов для разных типов сертификатов, что достигается соответствующей настройкой шаблонов сертификатов. В процессе выдачи разрешений на регистрацию сертификатов могут также использоваться имеющиеся в AD механизмы аутентификации и контроля доступа, базирующиеся на списках контроля доступа (ACL), которые могут быть заданы в шаблонах сертификатов
Ограничения по типам пользователей инфраструктуры PKI
Ориентируется на работу с инфраструктурой PKI пользователей Internet и внешних сетей
Ориентируется на работу с инфраструктурой PKI пользователей корпоративной сети
Требования по платформе
Данная версия может устанавливаться на контроллер домена (DC) Windows 2003, на сервер домена или на авто- номный сервер, не являющийся членом какого-либо домена.
Данная версия устанавливается только на контроллер домена (DC) Windows 2003 или на сервер домена
Поддерживаемые типы сертификатов
Может выдавать ограниченный набор типов сертификатов и сертификаты, требующие наличия специального идентификатора OID в расширении Extended Key Usage. Работа с шаблонами сертификатов не поддерживается
Может выпускать для среды Windows 2003 сертификаты любых типов из тех, которые представлены в оснастке Windows 2003 Certificate Templates. Поддерживаются шаблоны сертификатов версии 1 (Windows 2000 PKI) и версии 2 (Windows 2003 PKI)
Идентификация пользователей
При запросе сертификата пользователь должен ввести идентифицирующую его информацию вручную
Центр CA автоматически получает информацию, идентифицирующую пользователя, из AD
Управление пользователями
Пользователь регистрируется через Web-интерфейс. Можно также использовать утилиту командной строки c ertreq.exe
Пользователь регистрируется через Web-интерфейс или с помощью оснастки Certificates. Также существуют возможности автоматической регистрации сертификатов и регистрации с помощью утилиты командной строки certreq.exe
