Содержание статьи
Как известно, сертификаты нужны для надежной аутентификации, создания SSL-соединений, отправки S/MIME-сообщений и других действий, направленных на обеспечение безопасности. С каждым годом использование сертификатов растет, и для того, чтобы удовлетворять новым требованиям, Microsoft довольно серьезно переработала старую службу Certificate Services.
В Windows Server 2008 службы сертификации теперь относятся к службам Active Directory. Мы можем установить роль Active Directory Certificate Services (AD CS) и на сервер, не входящий в домен, но часть функций при этом будет недоступна. Например, для управления шаблонами требуется контроллер домена, так как шаблоны хранятся на нем. В состав роли AD CS в Windows Server 2008 R2 входит шесть компонентов:
- Certification authorities (CAs) – этот компонент позволяет установить и настроить корневой (root) или подчиненный (subordinate) центры сертификации (они же «удостоверяющие центры»), которые служат для выдачи сертификатов пользователям, компьютерам и службам.
- Web enrollment необходим для запроса сертификатов и получения информации об отозванных сертификатах через веб-браузер.
- Online Responder позволяет клиентам получать информацию о статусе одного сертификата без получения списков отзыва.
- Network Device Enrollment Service (NDES) используется маршрутизаторами и другими сетевыми устройствами без учетных записей в домене для получения сертификатов. Служба подачи заявок на сетевые устройства использует протокол SCEP (Simple Certificate Enrollment Protocol), который был разработан Cisco. Расширение NDES для IIS конфигурируется через ключи реестра HKEY_LOCAL_ROOT\Software\Microsoft\Cryptography\MSCEP.
- Certificate Enrollment Web Service позволяет клиентам автоматически подавать заявки на сертификаты и получать их по HTTPS.
- Certificate Enrollment Policy Web Service позволяет определить политики для автоматической регистрации сертификатов и передавать их клиентам по HTTPS. В то время, как Web Service получает информацию о политиках из AD по протоколу LDAP.
В предыдущих версиях Windows Server в состав Certificate Services входили только первые два компонента, которые назывались Certificate Services CA и Certificate Services Web Enrollment Support, а последние два компонента появились только в Windows Server 2008 R2.
Варианты установки и управления AD CS
AD CS нельзя установить на Itanium редакции Windows Server 2008, а на Server Core все компоненты AD CS можно устанавливать, начиная с Windows Server 2008 R2. Довольно серьезные ограничения по использованию AD CS присутствуют и в стандартной редакции Server 2008 (возможность установки только компонента CA, невозможность использовать Restricted Enrollment Agent и другие новшества), часть из которых были сняты в R2 (наконец в стандартной редакции появилась возможность работать с шаблонами сертификатов версий выше первой).
Все компоненты можно поставить на один сервер, но рекомендуется разносить CA, Online Responder и Web enrollment на различные сервера. Для полноценной работы AD CS требуется AD DS (Active Directory Domain Services). При этом можно обойтись без обновления схемы – AD CS в Server 2008 и в Server 2008 R2 будет работать и на схеме, которая поставляется с Windows Server 2003. Но для работы Certificate Enrollment Web Services уже необходима схема не ниже 47 версии, которая идет с Windows Server 2008 R2. Для работы большинства компонентов также требуется IIS.
Установка AD CS производится через добавление ролей в оснастке Server Manager. Как и раньше, для настройки параметров установки применяется конфигурационный файл CAPolicy.inf, который должен находиться в %SYSTEMROOT%. Если необходимо установить на сервер два компонента Certification Authority и Certificate Enrollment Web Service, то это надо делать в два этапа, так как при установке CA нельзя выбрать для установки компонент Web Service.
В Windows Server 2008 были добавлены новые COM-объекты (подробную информацию о свойствах ICertSrvSetup можно найти на MSDN), которые можно использовать для установки CA. Например, можно автоматизировать установку и настройку с помощью VBScript.
Службы сертификации являются хорошими кандидатами на виртуализацию. Но при этом очень важно обеспечить необходимый уровень безопасности для закрытых ключей. Этого можно достичь, используя аппаратные криптографические модули (HSM). В этом случае, даже если виртуалка целиком попадет к злоумышленнику (например, из резервной копии), то закрытые ключи не будут потеряны и не придется перестраивать всю инфраструктуру, так как ключи останутся в HSM. Microsoft официально поддерживает виртуализацию служб сертификации начиная с Windows Server 2003 SP1.
Для управления и настройки AD CS можно использовать MMC-оснастки, скрипты или командную строку. Большая часть инструментов существовала и в предыдущих версиях, таких как оснастки Certificates (certmgr.msc), Certification Authority (certsrv.msc) и Certificate Templates (certtmpl.msc), утилиты certutil.exe и сertreq.exe. Добавилась оснастка Online Responder Management (ocsp.msc) для управления одноименным компонентом. Кроме того, в состав ОС вошла оснастка Enterprise PKI (pkiview.msc), которая ранее была частью Windows Server 2003 Resource Kit и называлась PKI Health Tool.
Enterprise PKI позволяет одновременно отслеживать состояние и доступность нескольких CA, проверяет статус сертификатов CA, доступность AIA (Authority Information Access) и списков отзыва. С помощью разноцветных отметок можно судить о доступности и состоянии PKI. Pkiview удобно использовать, когда в организации развернуто несколько CA, и информацию о них можно получить из нескольких источников, работающих по различным протоколам.
Некоторые изменения произошли и в резервном копировании AD CS в Server 2008 R2. Так как закрытые ключи теперь хранятся в скрытой папке %SYSTEMDRIVE%\ProgramData\Microsoft\Crypto\Keys, к которой можно получить доступ через %SYSTEMDRIVE%\Users\All Users\Microsoft\Crypto\Keys, то они не попадают в резервную копию состояния системы. Чтобы можно было восстановить или мигрировать CA при создании использование в качестве резервной копии System State Backup, надо еще создать резервную копию закрытых ключей. Для этого можно воспользоваться командой certutil –backupKey <путь_для_резервной_копии> или оснасткой Certification Authority.
Шаблоны сертификатов
С помощью шаблонов сертификатов можно определить формат и содержимое издаваемого сертификата, а также задать разрешения на запрос сертификатов для пользователей и компьютеров. Только Enterprise CA могут использовать шаблоны сертификатов.
В Windows Server 2000 присутствовали только шаблоны первой версии, которые нельзя изменять – иначе говоря, можно использовать только те шаблоны, которые идут в составе ОС и задавать для них только разрешения на выдачу сертификатов. Шаблоны второй версии поддерживают восстановление и архивацию ключей, и автоматическую выдачу сертификатов (certificate autoenrollment) и были представлены в Windows Server 2003.
В Windows Server 2008 появились шаблоны версии 3, главная новая возможность которых – работа с CNG (Cryptography Next Generation). CNG – это замена CryptoAPI, в которой реализована поддержка алгоритмов из CryptoAPI 1.0 и поддержка ранее неподдерживаемых криптографических алгоритмов, среди которых алгоритмы ЭЦП и обмена ключами на основе эллиптических кривых, а также дополнительные алгоритмы хеширования. Стоит отметить, что использование сертификатов на основе NSA Suite B Cryptography (к которым относятся алгоритмы на основе эллиптических кривых) поддерживается только ОС, начиная с Windows Vista. То есть нельзя, например, использовать сертификат с ключом для алгоритма, использующего эллиптические кривые, в Windows XP и Windows Server 2003, хотя можно использовать классические алгоритмы, такие как RSA, даже если ключ был сгенерирован с использованием CNG. Использование шаблонов третьей версии для работы со смарт-картами также затруднено, так как CSP (Cryptography Service Provider) для смарт-карт не поддерживают новые алгоритмы CNG.
Вторая и третья версии шаблонов поддерживаются в редакциях Enterprise и Datacenter. В редакции Standard новые версии шаблонов поддерживаются только в Server 2008 R2. Сертификаты по шаблонам третьей версии можно издавать и на CA на Windows Server 2003.
В Windows Server 2008 R2 и Windows 7 был добавлен интерфейс программирования (Certificate Template API), который позволяет при установке приложения добавлять новые шаблоны сертификатов. Данная возможность может очень пригодиться, например, в такой ситуации: разработчики пишут приложение, которое использует сертификаты с нестандартными расширениями. Раньше надо были писать подробные инструкции для администраторов, чтобы они создали в своей системе необходимый шаблон. Теперь можно добавить новый шаблон программно с помощью импорта предварительно экспортированного шаблона, созданного в тестовой среде. Шаблон необходимо создавать через стандартную оснастку certtmpl.msc, чтобы быть уверенным, что он не нарушает огромное количество ограничений, которые накладываются на сертификаты (например, разрешение архивирования ключей только для сертификатов, которые используются для шифрования).
Новые способы запроса сертификатов
Кстати, а каким образом пользователи и компьютеры получают сертификаты? Иначе говоря, как они могут подавать запрос на сертификат и устанавливать его на компьютер? Можно, конечно, руками создать PKCS#10 запрос и с помощью командной строки и certreq передать запрос на CA, но не всегда есть возможность объяснить пользователям, как это сделать. Если пользователь доменный и подключен к корпоративной сети, то можно с помощью групповых политик настроить автоматическую подачу и обработку заявок. В результате пользователь может даже не подозревать, что ему был установлен новый сертификат или обновлен старый.
Клиенты, которые не входят в домен или не имеют прямого доступа в сеть с CA, могут запросить сертификат через веб-интерфейс. Компонент Web Enrollment, который необходим для этого, присутствовал и ранее, но был существенно переработан. Старая библиотека XEnroll.dll, которая была написана много лет назад и долго дополнялась новыми функциями и багами, была заменена на новую – CertEnroll.dll, так как оказалось легче написать с нуля, чем исправить то, что было. Web Enrollment позволяет подавать заявки в формате PKCS #10 или создавать запросы интерактивно через браузер, автоматическая подача заявок не поддерживается.
В Windows Server 2008 и более ранних версиях для аутентификации пользователей и компьютеров при запросе сертификатов использовался протокол Kerberos, а в качестве транспортного протокола – Distributed COM (DCOM). При таком способе аутентификации автоматическая подача заявок (autoenrollment) недоступна для компьютеров, которые не подсоединены к корпоративной сети, или для компьютеров, которые находятся в другом лесе, чем центр сертификации. CA Web Enrollment, появившийся в Server 2008 R2, использует для подачи заявок новый протокол WS-Trust. Новые сервисы – Certificate Enrollment Policy Web Service и Certificate Enrollment Web Service – позволяют получить политики и подать заявки на сертификаты через HTTPS. При этом в качестве аутентификации можно использовать не только Kerberos, но и пароли, и сертификаты.
Если необходимо избежать запросов к CA на новые сертификаты из интернета, но есть клиенты, которым надо обновлять сертификаты, когда они, например, в командировках, то можно использовать режим только обновления (renewal-only). В этом случае клиенты при первом получении сертификата должны быть в той же сети, что и CA, а в случае обновления сертификатов могут воспользоваться возможностями CA Web Enrollment.
Политики для этих служб настраиваются через групповые политики или на клиенте, через оснастку Certificates.
Списки отзыва vs. Online Responder
При проверке валидности сертификата среди прочего проверяется срок его действия и состояние отзыва. Сертификат может быть отозван, как в случае компрометации ключа, так и при изменении информации о владельце, например, смене должности или фамилии. Традиционно информация об отозванных сертификатах помещается в списки отзыва (CRL (certificate revocation list)). Чтобы узнать, был ли отозван сертификат, надо получить список отзыва и проверить наличие в нем рассматриваемого сертификата. Если в организации большое количество сертификатов, то список будет быстро расти, а клиенты при проверке статуса сертификата будут ждать закачки списка. Кроме обычных списков существуют еще и разностные (Delta CRL), которые содержат в себе только информацию о сертификатах, статус которых был изменен по сравнению с предыдущим списком отзыва. Delta CRL частично решают проблемы с объемом списков отзыва, но не решают всех проблем, связанных с актуальностью информации. Так как списки публикуются с заданным интервалом, то может быть такая ситуация, что сертификат уже отозван, а информации об этом в CRL еще нет.
В Windows Server 2008 появились сетевые ответчики (Online Responder). Их можно использовать как альтернативу или в дополнение к спискам отзыва сертификатов. Компонент Online Responder использует протокол OCSP (Online Certificate Status Protocol), описанный в RFC 2560. Ответчик разбирает запросы от клиентов, оценивает статус сертификата и отправляет обратно подписанный ответ с информацией о статусе запрошенного сертификата. В случае если клиенту требуется информация о статусе большого количества сертификатов, то целесообразно использовать списки отзыва, так как их достаточно получить один раз, без необходимости многократных запросов к серверу.
Протокол OCSP поддерживают клиенты, начиная с Windows Vista. Они могут быть настроены с помощью новых параметров групповой политики (Certificate Path Validation Settings вкладка Revocation).
В отличие от использования списков отзыва, Online Responder требуется вначале установить и настроить. Для этого надо выполнить следующие шаги:
- Добавить компонент Online Responder роли AD CS. Для работы Online Responder требуется IIS, который будет автоматически предложено установить.
- В свойствах CA для AIA указать путь, по которому доступен ответчик.
- Так как ответ о статусе сертификата подписывается, то для работы Online Responder требуется соответствующий сертификат. Сертификат, который будет использоваться ответчиком, должен обладать следующими атрибутами: короткий срок действия (несколько недель), наличие расширения id-pkix-ocsp-nocheck и расширенного использования ключа id-kp-OCSPSigning, отсутствие CDP и AIA. Эти атрибуты уже настроены в шаблоне OCSP Response Signing. В случае использования Enterprise CA надо только добавить его к доступным шаблонам в Active Directory, настроив на него разрешения (Read и Enroll) для сервера, на который установлен Online Responder. Для StandAlone CA надо еще менять значение соответствующего флага командой certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK. Действия по настройке шаблона в Windows Server 2003 отличаются и здесь не рассматриваются.
- На последнем этапе необходимо настроить сам сетевой ответчик. Для этого в оснастке Online Responder Management с помощью мастера надо создать revocation configuration.
- Для корректной работы Online Responder в период, когда происходит обновление ключа CA, необходимо разрешить обновления сертификатов Online Responder с использованием существующих ключей центра сертификации. Для этого надо выполнить на CA команду certutil -setreg ca\UseDefinedCACertInRequest 1. Данное действие необходимо для получения возможности подписывать ответы Online Responder с помощью сертификата, подписанного тем же ключом CA, который использовался для подписания сертификата, статус которого запрашивается.
В Windows 2003 для разрешения этой ситуации необходимо вручную создать столько сертификатов для подписи ответов OCSP, сколько требуется, чтобы покрыть срок действия двух сертификатов CA. При этом срок действия каждого из выпущенных сертификатов должен быть на две недели больше, чем у предыдущего.
Заключение
Видоизменения служб сертификации производились и в Windows Server 2008, и в R2. В итоге появились возможности, которые будут интересны специалистам по безопасности, инструменты, которые облегчат жизнь администратора, и функции, которые позволят пользователям еще меньше разбираться в сертификатах.
Во-первых, добивалась поддержка новых протоколов и криптографических алгоритмов. Протокол OCSP, который уже не один год присутствовал в других программных продуктах, наконец-то дошел до серверных ОС Microsoft. Таким образом, у администраторов и программистов появились различные варианты для проверки статуса отозванных сертификатов, которые позволяют выбирать между скоростью, объемом данных и актуальностью информации. Немаловажно и появление поддержки алгоритмов на эллиптических кривых. К сожалению, поддерживаются не российские, а американские стандарты, но ожидать иного было бы странно.
Во-вторых, многие библиотеки (например, Crypto API и XEnroll.dll) переписаны с нуля, из-за чего можно надеяться на избавление от старых ошибок и проблем, и ждать новых.
В-третьих, значительно расширились способы запроса и получения сертификатов. Теперь сертификаты могут получать и сетевые устройства без записи в домене, и пользователи без прямого доступа к сети с CA.
И наконец, без внимания не оставлены и любители автоматизации и скриптописания – новые объекты и функции позволят им реализовать свои фантазии.
