Шаблоны сертификатов в ms certificate services. Руководство по центрам сертификации. Выбор типа установки

• Перевод

Как вы уже должны знать, поддержка Windows Server 2003 и Windows Server 2003 R2 заканчивается 14 июля 2015 года. Зная это, ИТ профессионалы либо уже провели миграцию, либо этот процесс должен находиться в самом разгаре. В этой статье будут описаны шаги, необходимые для миграции Active Directory Certificate Service с Windows Server 2003 на Windows Server 2012 R2.

Для демонстрации будут использованы следующие установки:

Шаг 1. Резервная копия конфигурации и базы данных центра сертификации Windows Server 2003

Заходим в Windows Server 2003 под учетной записью из группы локальных администраторов.
Выбираем Start – Administrative Tools – Certificate Authority

Щелкаем правой кнопкой мыши по узлу сервера. Выбираем All Tasks , затем Back up CA

Откроется “Certification Authority Backup Wizard” и нажимаем “Next” для продолжения.


В следующем окне выбираете те пункты, которые подсвечены, чтобы указать нужные настройки и нажмите “ Browse ” для того, чтобы указать место сохранения резервной копии. Нажмите “Next” для продолжения.


Далее вам будет предложено ввести пароль для того, чтобы защитить закрытый ключ и файл сертификата центра сертификации. После того, как введете пароль, нажмите “Next” .

В следующем окне будет запрошено подтверждение. Если все в порядке – нажмите “ Finish ” для завершения процесса.

Шаг 2. Резервирование параметров реестра центра сертификации

Нажмите Start , затем Run . Напечатайте regedit и нажмите ОК .


Затем откройте HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
Щелкните правой кнопкой мыши по ключу “ Configuration ” и выберите “ Export ”


В следующем окне укажите путь, по которому вы хотите сохранить резервный файл и укажите его имя. Затем нажмите “Save” , чтобы закончить резервирование.


Теперь у нас есть резервные файлы центра сертификации и мы можем переместить эти файлы на новый сервер Windows Server 2012 R2.

Шаг 3. Удаление службы центра сертификации с Windows Server 2003

Теперь, когда готовы резервные файлы и прежде, чем настроить службы сертификации на новом Windows Server 2012 R2, мы можем удалить службы центра сертификации с Windows Server 2003. Для этого нужно проделать следующие шаги.
Щёлкаем Start > Control Panel > Add or Remove Programs


Затем выбираем “Add/Remove Windows Components”


В следующем окне уберите галочку с пункта “ Certificate Services ” и нажмите “ Next ” для продолжения


После завершения процесса, вы увидите подтверждение и можете нажать “ Finish ”


На этом этапе мы закончили работу со службами центра сертификации на Windows Server 2003 и следующим шагом будем настраивать и конфигурировать центра сертификации на Windows Server 2012 R2.

Шаг 4. Установка служб сертификации на Windows Server 2012 R2

Зайдите на Windows Server 2012 R2 под учетной записью или администратора домена, или локального администратора.
Перейдите в Server Manager > Add roles and features .


Запустится “Add roles and features” , нажмите “Next” для продолжения.
В следующем окне выберите “Role-based or Feature-based installation” , нажмите “Next” для продолжения.
Из списка доступных серверов выберите ваш, и нажмите “ Next ” для продолжения.
В следующем окне выберите роль “Active Directory Certificate Services”, установите все сопутсвующие компоненты и нажмите “ Next ” .


В следующих двух окнах нажимайте “ Next ” . После этого вы увидите варианты выбора служб для установки. Мы выбираем Certificate Authority и и нажимаем “Next” для продолжения.


Для установки Certification Authority Web Enrollment необходимо установить IIS . Поэтому в следующих двух окнах посмотрите краткое описание роли, выберите нужные компоненты и нажмите “ Next ” .
Далее вы увидите окно подтверждения. Если все в порядке, нажмите “ Install ” для того, чтобы начать процесс установки.


После того, как установка завершена, вы можете закрывать мастер установки и переходить к следующему шагу.

Шаг 5. Настройка AD CS

В этом шаге мы рассмотрим как настроить и восстановить те файлы резервирования, которые мы создали.
Зайдите на сервере с правами Enterprise Administrator
Перейдите в Server Manager > AD CS


C правой стороны на панели вы увидите всплывающее окно, как на скриншоте и нажмите “ More ”


Откроется окно, в котором вам нужно нажать “Configure Active Directory Certification Service…”


Откроется окно мастера настройки роли, в котором появится возможность изменить учетную запись. Т.к. мы уже вошли в систему с учетной записью Enterprise Administrator , то мы оставим то, что указано по умолчанию и нажмем “ Next ”


В следующем окне спросят, каким службы мы хотим настроить. Выберите Certificate Authority и Certification Authority Web Enrollment и нажимаем “Next” для продолжения.


Это будет Enterprise CA , поэтому в следующем окне выберите в качестве типа установки Enterprise CA и нажмите “ Next ” для продолжения.


В следующем окне выберите “Root CA” в качестве типа CA и нажмите “ Next ” для продолжения.


Следующая настройка очень важна. Если бы это была новая установка, то мы могли бы просто создать новый закрытый ключ. Но так как это процесс миграции, у нас уже есть зарезервированный закрытый ключ. Поэтому здесь выберите вариант, который отмечен на скриншоте и нажмите “ Next ” для продолжения.


В следующем окне нажмите кнопку “ Import ” .


Здесь у нас появляется возможность выбрать тот ключ, который мы зарезервировали с Windows Server 2003. Указываем путь к этому ключу и вводим пароль, который мы использовали. Затем нажимаем OK .


Далее, если импорт прошел успешно, то мы увидим наш сертификат. Выбираем его и нажимаем “ Next ” для продолжения.


В следующем окне мы можем определить путь к базе данных сертификата. Я оставил то, что указано по умолчанию и нажимаю “Next” для продолжения.


В следующем окне будет предоставлена вся информация для настройки. Если все нормально, то нажимаем “Configuration” для запуска процесса.


После того, как процесс завершен, закрываем мастера конфигурации.

Шаг 6. Восстановление зарезервированного CA

Теперь мы переходим к наиболее важной части всего процесса миграции, в которой мы восстановим зарезервированный в Windows Server 2003 CA.
Открываем Server Manager > Tools > Certification Authority


Щелкаете правой кнопкой мыши по имени сервера и выбираете All Tasks > Restore CA


Далее появится предупреждение о том, что служба сертификатов должна быть установлена для продолжения. Нажмите ОК .


Запустится Certification Authority Restore Wizard , нажмите “Next” для продолжения.
В следующем окне укажите путь к папке, в которой находится резервная копия. Затем выберите теже настройки, что и я на скриншоте. Нажмите “ Next ” для продолжения.


В следующем окне вы можете ввести пароль, который мы использовали для того, чтобы защитить закрытый ключ в процессе резервирования. После ввода, нажмите “Next” для продолжения.


В следующем окне нажмите “ Finish ” для завершения процесса импорта.
После успешного завершения процесса, система спросит, можно ли запустить центр сертификации. Запустите службу.

Шаг 7. Восстановление информации в реестре

Во время создания резервной копии CA мы также создали резервную копию ключа реестра. Теперь нужно ее восстановить. Для этого откройте папку, которая содержит зарезервированный ключ реестра. Щелкните по нему дважды левой кнопкой мыши.
Появится предупреждающее окно. Нажмите “ Yes ” для восстановления ключа реестра.


По окончании вы получите подтверждение об успешном восстановлении.

Шаг 8. Перевыпуск шаблона сертификата

Мы завершили процесс миграции, и сейчас нужно перевыпустить сертификаты. У меня были настройки шаблона в окружении Windows Server 2003, который назывался “ PC Certificate ” , с помощью которого выпускались сертификаты для компьютеров, включенных в домен. Теперь посмотрим, как я перевыпущу шаблон.
Открывает консоль Certification Authority
Щелкаем правой кнопкой мышки по Certificate Templates Folder > New > Certificate Template to Reissue .


Из списка шаблонов сертификатов выберите подходящий шаблон сертификата и нажмите ОК .

Шаг 9. Тестируем CA

Теперь, когда шаблон сертификата установлен на компьютер, его нужно установить на автоматический режим. Для проверки я установил компьютер с операционной системой Windows 8.1 , назвал его demo 1 и добавил в домен canitpro.local . После его первой загрузки, на сервере я открываю консоль центра сертификации и разворачиваю раздел “Issued Certificate”. Там я могу увидеть новый сертификат, который выпущен для компьютера.

На этом процесс миграции успешно завершен.

Как известно, сертификаты нужны для надежной аутентификации, создания SSL-соединений, отправки S/MIME-сообщений и других действий, направленных на обеспечение безопасности. С каждым годом использование сертификатов растет, и для того, чтобы удовлетворять новым требованиям, Microsoft довольно серьезно переработала старую службу Certificate Services.

В Windows Server 2008 службы сертификации теперь относятся к службам Active Directory. Мы можем установить роль Active Directory Certificate Services (AD CS) и на сервер, не входящий в домен, но часть функций при этом будет недоступна. Например, для управления шаблонами требуется контроллер домена, так как шаблоны хранятся на нем. В состав роли AD CS в Windows Server 2008 R2 входит шесть компонентов:

1. Certification authorities (CAs) – этот компонент позволяет установить и настроить корневой (root) или подчиненный (subordinate) центры сертификации (они же «удостоверяющие центры»), которые служат для выдачи сертификатов пользователям, компьютерам и службам.
2. Web enrollment необходим для запроса сертификатов и получения информации об отозванных сертификатах через веб-браузер.
3. Online Responder позволяет клиентам получать информацию о статусе одного сертификата без получения списков отзыва.
4. Network Device Enrollment Service (NDES) используется маршрутизаторами и другими сетевыми устройствами без учетных записей в домене для получения сертификатов. Служба подачи заявок на сетевые устройства использует протокол SCEP (Simple Certificate Enrollment Protocol), который был разработан Cisco. Расширение NDES для IIS конфигурируется через ключи реестра HKEY_LOCAL_ROOT\Software\Microsoft\Cryptography\MSCEP.
5. Certificate Enrollment Web Service позволяет клиентам автоматически подавать заявки на сертификаты и получать их по HTTPS.
6. 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 требуется вначале установить и настроить. Для этого надо выполнить следующие шаги:

1. Добавить компонент Online Responder роли AD CS. Для работы Online Responder требуется IIS, который будет автоматически предложено установить.
2. В свойствах CA для AIA указать путь, по которому доступен ответчик.
3. Так как ответ о статусе сертификата подписывается, то для работы 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 отличаются и здесь не рассматриваются.
4. На последнем этапе необходимо настроить сам сетевой ответчик. Для этого в оснастке Online Responder Management с помощью мастера надо создать revocation configuration.
5. Для корректной работы 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.

И наконец, без внимания не оставлены и любители автоматизации и скриптописания – новые объекты и функции позволят им реализовать свои фантазии.

Применимо к:Windows Server 2012 R2, Windows Server 2012

Центр сертификации (ЦС) отвечает за подтверждение личности пользователей, а также за подтверждение подлинности компьютеров и организаций. Центр сертификации выполняет аутентификацию объектов и подтверждает их подлинность выпуском сертификата с цифровой подписью. Центр сертификации также может управлять сертификатами, осуществлять их отзыв и продление.

В роли центра сертификации могут выступать:

организация, подтверждающая личность пользователя;

сервер, используемый организацией для выпуска сертификатов и управления ими.

Установив службу роли центра сертификации для служб сертификатов Active Directory (AD CS), можно настроить сервер Windows Server в качестве ЦС.

Перед установкой службы роли ЦС следует выполнить следующие действия:

спланировать инфраструктуру открытых ключей (PKI) в соответствии с требованиями организации;

установить и настроить аппаратный модуль безопасности (HSM) в соответствии с инструкциями его изготовителя, если вы планируете использовать такой модуль;

создать соответствующий файл CAPolicy.inf, если необходимо изменить параметры установки по умолчанию.

Планирование инфраструктуры открытых ключей

Чтобы организация могла в полной мере использовать возможности служб сертификатов Active Directory (AD CS), необходимо правильно спланировать развертывание инфраструктуры PKI. Перед установкой любого ЦС следует определить, сколько ЦС будет установлено и в какой конфигурации. Правильное проектирование инфраструктуры PKI может занять немало времени, но оно необходимо для успешного развертывания.

Дополнительные сведения и ресурсы см. в документе на сайте Microsoft TechNet.

Использование аппаратного модуля безопасности

С помощью аппаратного модуля безопасности (HSM) можно повысить безопасность ЦС и инфраструктуры PKI.

Модуль HSM - это специальное устройство, управление которым осуществляется независимо от операционной системы. Оно предоставляет защищенное аппаратное хранилище для ключей ЦС, а также специальный криптографический процессор для ускоренного подписания и шифрования. Операционная система использует модуль HSM посредством интерфейсов CryptoAPI. При этом модуль HSM выступает в роли устройства-поставщика служб шифрования (CSP).

Обычно модули HSM представляют собой адаптеры PCI, но это также могут быть сетевые, последовательные устройства и устройства USB. Если организация планирует развернуть два ЦС или более, вы можете установить один сетевой модуль HSM, который будет использоваться несколькими ЦС.

Чтобы настроить ЦС с помощью ключей, которые будут храниться в модуле HSM, необходимо предварительно установить и настроить этот модуль.

Использование файла CAPolicy.inf

Файл CAPolicy.inf не требуется для установки служб AD CS, но с его помощью можно настроить параметры ЦС. Файл CAPolicy.inf содержит различные параметры, которые используются при установке ЦС или продлении сертификата ЦС. Для использования файла CAPolicy.inf его необходимо создать и хранить в каталоге %systemroot% (обычно C:\Windows).

Параметры, включаемые в файл CAPolicy.inf, в основном зависят от типа создаваемого развертывания. Например, для корневого ЦС файл CAPolicy.inf может выглядеть так:

Signature= "$Windows NT$" RenewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=20 LoadDefaultTemplates=0

В то время как для организации, предоставляющей ЦС, файл CAPolicy.inf может выглядеть так:

Signature= "$Windows NT$" Policies = LegalPolicy, LimitedUsePolicy OID = 1.1.1.1.1.1.1.1.1 URL = "http://www.contoso.com/pki/Policy/USLegalPolicy.asp" URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt" OID = 2.2.2.2.2.2.2.2.2 URL = "http://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp" URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt" LoadDefaultTemplates=0

Примечание

Идентификаторы объектов, приведенные в образцах файла CAPolicy.inf, - это только примеры. Каждая организация должна получить свой идентификатор объекта (OID). Дополнительные сведения об идентификаторах объектов см. в статье Получение корневого идентификатора объекта из центра регистрации имен ISO .

Дополнительные сведения см. в разделе .

Выбор параметров конфигурации ЦА

В следующих разделах описываются параметры конфигурации, которые необходимо выбрать после установки двоичных установочных файлов ЦС.

Выбор типа установки

ЦС предприятия интегрированы с доменными службами Active Directory (AD DS). Они публикуют сертификаты и списки отзыва сертификатов в AD DS. ЦС предприятия используют информацию, хранящуюся в AD DS, включая сведения об учетных записях пользователей и группах безопасности, для утверждения или отклонения запросов сертификатов. ЦС предприятия используют шаблоны сертификатов. При выдаче сертификата ЦС предприятия использует информацию из шаблона с целью создания сертификата с атрибутами, соответствующими этому типу сертификатов.

Чтобы обеспечить автоматическое утверждение сертификатов и автоматическую регистрацию сертификатов пользователей, используйте ЦС предприятия для выдачи сертификатов. Эти возможности доступны, только если инфраструктура ЦС интегрирована с Active Directory. Кроме того, только ЦС предприятия могут выдавать сертификаты, обеспечивающие вход по смарт-картам, так как для этого требуется автоматическое сопоставление сертификатов смарт-карт с учетными записями пользователей в Active Directory.

Примечание

По умолчанию устанавливать и настраивать ЦС предприятия могут только члены группы администраторов предприятия. Если требуется предоставить полномочия для установки и настройки ЦС предприятия администраторам домена с более низким уровнем прав, выполните инструкции из раздела Делегированная установка центра сертификации предприятия .

Изолированные ЦС не требуют наличия служб AD DS и не используют шаблоны сертификатов. Если используются изолированные ЦС, вся информация о типе запрошенного сертификата должна включаться в запрос на сертификат. По умолчанию, все запросы на сертификаты, отправленные в изолированные ЦС, помещаются в очередь ожидания, пока администратор ЦС не утвердит их. В изолированных ЦС можно настроить автоматическую выдачу сертификатов при поступлении запросов, но делать это обычно не рекомендуется, так как аутентификация запросов не производится и безопасность снижается.

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

Изолированные ЦС необходимо использовать для выдачи сертификатов, если применяется служба каталогов не от корпорации Майкрософт или если службы AD DS недоступны. В организации можно одновременно использовать центры сертификации предприятия и изолированные центры сертификации, как описывается в приведенной ниже таблице.

Параметр	ЦС предприятия	Изолированный ЦС
Публикация сертификатов в Active Directory и использование Active Directory для проверки запросов на сертификаты.
Отключение ЦС от сети.
Настройка ЦС на автоматическую выдачу сертификатов.
Возможность утверждения запросов на сертификаты администраторами вручную.
Возможность использования шаблонов сертификатов.
Аутентификация запросов в Active Directory.

Выбор типа ЦС

ЦС предприятия и изолированные ЦС можно настроить как корневые или подчиненные. Подчиненные ЦС, в свою очередь, можно настроить как промежуточные (также называемые ЦС политик) или выдающие.

Назначение корневого ЦС

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

Так как корневой ЦС является вершиной иерархии сертификации, поле субъекта в сертификате, выданном им, имеет то же значение, что и поле издателя. Аналогичным образом, так как цепочка сертификатов завершается при достижении самозаверяющего ЦС, все самозаверяющие ЦС являются корневыми. Решение о назначении ЦС доверенным корневым ЦС может приниматься на уровне всего предприятия или локально отдельными ИТ-администраторами.

Корневой ЦС служит основной, на которой строится модель отношений доверия центров сертификации. Он гарантирует, что открытый ключ субъекта соответствует информации в поле субъекта сертификатов, выдаваемых им. Разные ЦС могут проверять это соответствие с помощью различных стандартов. Поэтому перед тем как доверять корневому центру сертификации проверку открытых ключей, необходимо разобраться в том, какие политики и процедуры используются им.

Корневой ЦС - это самый важный ЦС в вашей иерархии. Если его безопасность нарушена, то безопасность всех ЦС в иерархии и всех выданных ими сертификатов также считается нарушенной. Чтобы максимально повысить безопасность корневого ЦС, его можно не подключать к сети и использовать подчиненные ЦС для выдачи сертификатов другим подчиненным ЦС или конечным пользователям.

Подчиненные ЦС

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

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

Предупреждение

Корневой ЦС нельзя преобразовать в подчиненный и наоборот.

Хранение закрытого ключа

Закрытый ключ - это часть удостоверения ЦС, которую необходимо защищать от несанкционированного доступа. Многие организации защищают закрытые ключи ЦС с помощью аппаратного модуля безопасности (HSM). Если модуль HSM не используется, закрытый ключ хранится на компьютере ЦС. Дополнительные сведения см. в статье на сайте Microsoft TechNet.

ЦС, не подключенные к сети, должны находиться в безопасных расположениях. Выдающие ЦС используют закрытые ключи при выдаче сертификатов, поэтому эти ключи должны быть доступны, когда ЦС работает. В любом случае ЦС и его закрытые ключи должны быть физически защищены.

Поиск существующего ключа

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

Поиск существующего сертификата

Если у вас уже есть сертификат, который содержит закрытый ключ для ЦС, найти его можно на экране Существующий сертификат . Чтобы открыть диалоговое окно Импорт существующего сертификата , а затем найти существующий файл PKCS #12, можно нажать кнопку Импорт .

Выбор параметров шифрования

Выбор параметров шифрования для центра сертификации (ЦС) может оказать значительное влияние на его безопасность, производительность и совместимость. Хотя для большинства ЦС может быть достаточно параметров шифрования по умолчанию, возможность применения настраиваемых параметров может быть полезна для администраторов и разработчиков приложений с более глубоким пониманием принципов шифрования и потребностью в гибкой настройке. Параметры шифрования можно реализовать с помощью поставщиков служб шифрования (CSP) или поставщиков хранилищ ключей (KSP).

При использовании сертификата RSA для ЦС длина ключа должна быть не менее 2048 бит. Для ЦС не следует пытаться использовать сертификат RSA с длиной ключа менее 1024 бит. Служба ЦС (certsvc) не запустится, если установлен ключ RSA длиной менее 1024 бит.

Поставщики CSP - это аппаратные и программные компоненты в операционных системах Windows, которые предоставляют общие функции шифрования. Написание поставщиков CSP позволяет реализовывать различные алгоритмы шифрования и подписания.

Поставщики KSP с помощью ключей обеспечивают надежную защиту компьютеров, работающих под управлением минимальной серверной версии Windows Server 2008 R2 или минимальной клиентской версии операционной системы Windows Vista.

При выборе поставщика, хэш-алгоритма и длины ключа следует учитывать, какие параметры шифрования поддерживают приложения и устройства, которые планируется использовать. Рекомендуется всегда выбирать самый высокий уровень безопасности, однако не все приложения и устройства его поддерживают.

Если в результате изменения требований поддержки вы получаете возможность применить более надежные параметры безопасности, например перенос в KSP, и более строгий хэш-алгоритм, воспользуйтесь рекомендациями из раздела Миграция ключа центра сертификации из поставщика служб шифрования (CSP) в поставщик хранилища ключей (KSP) .

Разрешить взаимодействие с администратором, если ЦС обращается к закрытому ключу - это параметр, который обычно используется с аппаратными модулями безопасности (HSM). Он позволяет поставщику служб шифрования запрашивать у пользователя дополнительные данные для аутентификации при доступе к закрытому ключу ЦС. Этот параметр помогает предотвратить несанкционированное использование ЦС и его закрытого ключа благодаря тому, что администратор должен вводить пароль перед каждой операцией шифрования.

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

Поставщик служб шифрования	Длины ключей	Хеш-алгоритм
Microsoft Base Cryptographic Provider версии 1.0
Microsoft Base DSS Cryptographic Provider
Microsoft Base Smart Card Crypto Provider
Microsoft Enhanced Cryptographic Provider версии 1.0
Microsoft Strong Cryptographic Provider
RSA#Microsoft Software Key Storage Provider
DSA#Microsoft Software Key Storage Provider
ECDSA_P256#Microsoft Software Key Storage Provider
ECDSA_P384#Microsoft Software Key Storage Provider
ECDSA_P521#Microsoft Software Key Storage Provider
RSA#Microsoft Smart Card Key Storage Provider
ECDSA_P256#Microsoft Smart Card Key Storage Provider
ECDSA_P384#Microsoft Smart Card Key Storage Provider
ECDSA_P521#Microsoft Smart Card Key Storage Provider

Создание имени ЦС

Перед настройкой центров сертификации (ЦС) в организации следует определить соглашение об именовании ЦС.

Создать имя можно с помощью символов стандарта "Юникод", однако, если возможность взаимодействия имеет особую важность, следует использовать кодировку ANSI. Например, маршрутизаторы некоторых типов не смогут использовать службу регистрации сертификатов для сетевых устройств, если имя ЦС содержит специальные символы, такие как символ подчеркивания.

Если используются нелатинские символы (например, символы кириллицы, арабского или китайского алфавита), имя ЦС должно содержать менее 64 символов. Если используются только нелатинские символы, длина имени ЦС не может превышать 37 символов.

В доменных службах Active Directory (AD DS) имя, которое вы указываете при настройке сервера в качестве ЦС, становится общим именем ЦС и указывается в каждом выдаваемом им сертификате. По этой причине важно не использовать полное доменное имя в качестве общего имени ЦС. Таким образом, злоумышленник, получивший копию сертификата, не сможет определить и использовать полное доменное имя ЦС для создания уязвимости в системе безопасности.

Предупреждение

Имя ЦС не должно совпадать с именем компьютера (именем NetBIOS или DNS). Кроме того, если вы измените имя сервера после установки служб сертификатов Active Directory (AD CS), все выданные ЦС сертификаты станут недействительны. Дополнительные рекомендации, касающиеся имен ЦС, можно найти в следующей вики-статье TechNet: Рекомендации по составлению имен центров сертификации (ЦС) .

Чтобы изменить имя сервера после установки служб AD CS, необходимо удалить ЦС, изменить имя сервера, повторно установить ЦС, используя те же ключи, и изменить реестр так, чтобы использовались существующие ключи и база данных ЦС. Переустанавливать ЦС при переименовании домена не нужно. Однако вам потребуется перенастроить ЦС в соответствии с новым именем.

Получение запроса на сертификат

После установки корневого центра сертификации (ЦС) многие организации устанавливают один подчиненный ЦС или несколько с целью реализации ограничений в инфраструктуре открытых ключей (PKI) с помощью политик и выдачи сертификатов конечным клиентам. Использование даже одного подчиненного ЦС может помочь защитить корневой ЦС от лишнего доступа. При установке подчиненного ЦС необходимо получить сертификат от родительского ЦС.

Если родительский ЦС подключен к сети, вы можете использовать параметр Отправить запрос сертификата в родительский ЦС и выбрать родительский ЦС по имени ЦС или имени компьютера.

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

Если вы получили сертификат подчиненного ЦС, который не содержит полного пути сертификации, новый подчиненный ЦС, который вы устанавливаете, должен иметь возможность построения действительной цепочки ЦС при запуске. Чтобы создать действительный путь сертификации, выполните указанные ниже действия.

Установите сертификат родительского ЦС в хранилище сертификатов Промежуточные центры сертификации на компьютере, если родительский ЦС не является корневым.

Установите сертификаты всех остальных промежуточных ЦС в цепочке.

Установите сертификат корневого ЦС в хранилище "Доверенные корневые центры сертификации".

Примечание

Эти сертификаты должны быть установлены в хранилище сертификатов до установки сертификата ЦС в только что настроенном подчиненном ЦС.

Проверка срока действия

Шифрование на основе сертификатов использует механизм шифрования с открытым ключом для защиты и подписания данных. Со временем злоумышленники могут получить данные, защищенные с помощью открытого ключа, чтобы попытаться извлечь из них закрытый ключ. При наличии достаточного количества времени и ресурсов закрытый ключ можно взломать, из-за чего все защищенные данные лишатся защиты. Кроме того, через некоторое время может потребоваться изменить имена, защищаемые с помощью сертификата. Так как сертификат обеспечивает привязку имени к открытому ключу, при изменении того или другого сертификат следует обновить.

У каждого сертификата есть срок действия. По истечении срока действия сертификат больше не считается пригодным для использования или заслуживающим доверия.

ЦС не могут выдавать сертификаты, срок действия которых превышает их собственный. Сертификат ЦС рекомендуется обновлять, когда истекла половина его срока действия. При установке ЦС следует учесть эту дату и указать ее как дату запланированной к выполнению задачи.

Выбор базы данных ЦС

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

Расположение базы данных сертификатов и ее файлов журналов хранится в реестре в следующем разделе:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

Раздел содержит следующие параметры:

• DBSystemDirectory

Примечание

Базу данных сертификатов и файлы журналов можно переместить после установки. Дополнительная информация доступна в статье 283193 базы знаний Майкрософт.

Настройка ЦС

После установки корневого или подчиненного ЦС необходимо настроить расширения доступа к информации о центрах сертификации (AIA) и точки распространения списка отзыва сертификатов (CDP), прежде чем ЦС начнет выпускать сертификаты. Расширение AIA указывает, где находятся актуальные сертификаты для ЦС. Расширение CDP указывает, где находятся актуальные списки отзыва сертификатов, подписанные ЦС. Эти расширения применяются ко всем сертификатам, выдаваемым ЦС.

Настройка этих расширений гарантирует, что данная информация включается в каждый сертификат, выдаваемый ЦС, и доступна всем клиентам. Благодаря этому клиенты PKI будут испытывать минимальное возможное количество сбоев из-за непроверенных цепочек сертификатов или отозванных сертификатов, которые могут приводить к неудавшимся попыткам подключения к VPN, неудавшимся попыткам входа по смарт-картам или непроверенным подписям электронной почты.

Администратор ЦС может добавлять, удалять или изменять точки распространения списков отзыва сертификатов, а также расположения выдачи сертификатов CDP и AIA. Изменение URL-адреса точки распространения списка отзыва сертификатов затрагивает только сертификаты, которые будут выдаваться в дальнейшем. Ранее выданные сертификаты будут по-прежнему ссылаться на исходное расположение. Вот почему эти расположения следует указывать до того, как ЦС начнет распространять сертификаты.

При настройке URL-адресов для расширения CDP примите во внимание приведенные ниже рекомендации.

Избегайте публикации разностных списков отзыва сертификатов в автономных корневых ЦС. Так как сертификаты в автономном корневом ЦС отзываются не часто, скорее всего, разностный список отзыва сертификатов не нужен.

Скорректируйте URL-расположения по умолчанию (LDAP:/// и HTTP://) на вкладке Расширения страницы Расширение свойств центра сертификации согласно вашим требованиям.

Опубликуйте список отзыва сертификатов в HTTP-расположении в Интернете или экстрасети, чтобы пользователи и приложения вне организации могли выполнять проверку сертификата. Можно опубликовать URL-адреса LDAP и HTTP для расположений CDP, чтобы дать клиентам возможность получать данные списка отзыва сертификатов по HTTP и LDAP.

Помните, что клиенты Windows всегда получают список URL-адресов последовательно, пока не будет получен действительный список отзыва сертификатов.

Используйте HTTP-расположения CDP для обеспечения доступа к спискам отзыва сертификатов со стороны клиентов с операционными системами, отличными от Windows.

Примечание

Дополнительные сведения о списках отзыва сертификатов (в том числе разностных) см. в статье .

Среда Windows PowerShell и certutil поддерживают переменные значения (со знаком процента (%) перед ними) при публикации расположений CDP и AIA. На вкладке Расширение свойств ЦС поддерживаются переменные в скобках. В приведенной ниже таблице сопоставляются переменные из разных интерфейсов и описываются их значения.

Переменная	Имя на вкладке расширений	Описание
	<имя_DNS-сервера>	DNS-имя компьютера ЦС. Если компьютер подключен к домену DNS, это полное доменное имя. В противном случае это имя узла компьютера.
	<сокращенное_имя_сервера>	Имя NetBIOS сервера ЦС
	<имя_ЦС>
	<имя_сертификата>	Позволяет каждой дополнительной редакции сертификата иметь уникальный суффикс.
		Не используется
	<контейнер_конфигураций>	Расположение контейнера конфигурации в доменных службах Active Directory (AD DS)
	<усеченное_имя_ЦС>	Имя ЦС, усеченное до 32 символов, со знаком "решетка" (#) в конце
	<суффикс_имени_CLR>	Добавляет суффикс к имени файла при публикации списка отзыва сертификатов в файле или по URL-адресу.
	<разностный_список_разрешен>	При публикации разностного списка отзыва сертификатов заменяет переменную CRLNameSuffix отдельным суффиксом для различения разностного и обычного списка отзыва сертификатов.
	<класс_объектов_CDP>	Идентификатор класса объектов для точек распространения списков отзыва сертификатов, который используется при публикации по URL-адресу LDAP.
	<класс_объектов_ЦС>	Идентификатор класса объектов для ЦС, который используется при публикации по URL-адресу LDAP.

Публикация расширения AIA

Расширение AIA сообщает клиентским компьютерам, где можно найти сертификат, подлежащий проверке. Таким образом клиент может убедиться в том, что сертификату можно доверять.

Расширение AIA можно настроить с помощью интерфейса центра сертификации, среды Windows PowerShell или команды certutil. В таблице ниже описываются параметры, которые можно задать для расширения AIA при использовании этих методов.

В примерах публикации расширения AIA в этом разделе используется указанный ниже сценарий.

Первый протокол, который клиентские компьютеры должны использовать для получения информации AIA, - HTTP.

Второй протокол, который клиентские компьютеры должны использовать для получения информации AIA, - LDAP.

Протокол OCSP не используется.

Публикация расширения AIA с помощью интерфейса

Имена переменных и параметров, используемых в интерфейсе, приведены в таблицах выше. Получить доступ к этому интерфейсу можно через интерфейс центра сертификации. На панели содержимого щелкните ЦС правой кнопкой мыши, выберите пункт Свойства , а затем пункт Расширения . В списке Выберите расширение: выберите пункт Доступ к сведениям о центрах сертификации (AIA) .

Рис. 1. Меню расширения AIA

В пользовательском интерфейсе настраиваются следующие расположения и параметры:

C:\Windows\system32\CertSrv\CertEnroll\<имя_DNS-сервера>_<имя_ЦС><имя_сертификата>.crt

Добавить локальный путь с помощью командлета Windows PowerShell Add-CAAuthorityInformationAccess невозможно. Сертификат ЦС будет автоматически опубликован в расположении по умолчании: %systemroot%\system32\CertSrv\CertEnroll.

Публикация расширения AIA с помощью команды certutil

Можно воспользоваться командой certutil, чтобы настроить расширение AIA для следующего сценария.

Certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://www.contoso.com/pki/%1_%3%4.crt\n1:file://\\App1.corp.contoso.com\pki\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Примечание

После изменения этих путей обязательно перезапустите службу CertSvc. Для этого можно выполнить следующую команду Windows PowerShell: restart-service certsvc

В команде certutil все пути следует указывать в виде одной непрерывной строки, заключенной в кавычки. Каждый путь отделяется символом \n.

Публикация расширения CDP

Расширение CDP сообщает клиентским компьютерам, где находится самый последний список отзыва сертификатов. Таким образом клиент может проверить, не отозван ли определенный сертификат.

Расширение CDP можно настроить с помощью интерфейса центра сертификации, среды Windows PowerShell или команды certutil. В таблице ниже описываются параметры, которые можно задать для расширения CDP при использовании этих методов.

Имя параметра в интерфейсе	Параметр Windows PowerShell	Значение в Certutil
	PublishToServer
Включить во все CRL. (Указывает место публикации в Active Directory при ручной публикации.)
Включить в CRL. (Клиенты используют данные для поиска в размещениях Delta CRL.)	AddToFreshestCrl
Включать в CDP-расширение выданных сертификатов	AddToCertificateCdp
	PublishDeltaToServer
Включать в расширение IDP выданных CRL

Примечание

Расширение выдающей точки распространения (IDP) используется клиентами, отличными от Windows, для проверки отзыва сертификатов. Расширение IDP позволяет развертывать разделенные списки отзыва сертификатов при использовании сторонних ЦС. Разделенные списки отзыва сертификатов позволяют стороннему ЦС публиковать списки отзыва сертификатов, каждый из которых содержит сертификаты только определенных типов. Например, можно создать отдельные списки отзыва сертификатов для конечных сертификатов и сертификатов ЦС. В частности, в IDP можно задать указанные ниже параметры.

onlyContainUserCerts. Этот параметр IDP допускает наличие только таких сертификатов, в расширении "Основные ограничения" которых нет значения cA. Если сертификат не содержит расширение "Основные ограничения", то предполагается, что это не сертификат ЦС.

onlyContainsCACerts. Этот параметр IDP допускает включение в список отзыва сертификатов только тех сертификатов, расширение "Основные ограничения" которых имеет значение cA.

Если разрешена публикация разностных списков отзыва сертификатов на веб-сервере IIS, необходимо изменить конфигурацию IIS по умолчанию, задав атрибут allowDoubleEscaping=true элемента requestFiltering в разделе system.web конфигурации IIS. Например, чтобы разрешить двойное преобразование для виртуального каталога PKI веб-сайта IIS по умолчанию, выполните на веб-сервере IIS следующую команду: appcmd set config "Default Web Site/pki" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true. Дополнительную информацию можно найти в статье: .

В примерах публикации расширения CDP в этом разделе используется указанный ниже сценарий.

Доменное имя - corp.contoso.com.

В домене есть веб-сервер с именем App1.

На сервере App1 есть общая папка с именем PKI, для которой ЦС предоставлены разрешения на чтение и запись.

Сервер App1 имеет DNS-запись CNAME со значением www и общий виртуальный каталог с именем PKI.

Первый протокол, который клиентские компьютеры должны использовать для получения информации CDP, - HTTP.

Второй протокол, который клиентские компьютеры должны использовать для получения информации CDP, - LDAP.

Настраиваемый ЦС представляет собой подключенный к сети выдающий ЦС.

IDP не используется.

Публикация расширения CDP с помощью интерфейса

Имена переменных и параметров, используемых в интерфейсе, приведены в предыдущих таблицах. Получить доступ к этому интерфейсу можно через интерфейс центра сертификации. На панели содержимого щелкните ЦС правой кнопкой мыши, выберите пункт Свойства , а затем пункт Расширения . В списке Выберите расширение: выберите пункт Точка распространения списков отзыва (CDP) .

Рис. 2. Меню расширения CDP

В интерфейсе настраиваются следующие расположения и параметры:

C:\Windows\System32\CertSrv\CertEnroll\<имя_СЦС><суффикс_имени_CLR><разностные_CRL_разрешены>.crl

• Публикация разностных CRL по адресу

• Публикация расширения CDP с помощью команды certutil

  Команда certutil позволяет настроить расширение CDP для заданного сценария:

  Certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:http://www.contoso.com/pki/%3%8%9.crl\n65:file://\\App1.corp.contoso.com\pki\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

  Примечание

  После изменения этих путей обязательно перезапустите службу ЦС. В Windows PowerShell можно перезапустить CertSvc, выполнив следующую команду: restart-service certsvc

  В команде certutil введите все пути в виде одной непрерывной строки, заключенной в кавычки, но разделите пути символом \n.

  Чтобы опубликовать список отзыва сертификатов, можно выполнить команду certutil -crl в ЦС из Windows PowerShell или из командной строки от имени администратора. Дополнительные сведения о настройке и публикации CRL см. в разделе .

  Проверка конфигурации

  Чтобы проверить конфигурацию ЦС, можно выполнить указанные ниже команды в Windows PowerShell или окне командной строки.

  Для проверки конфигураций публикации AIA и CDP можно воспользоваться средством просмотра инфраструктуры PKI предприятия (PKIView.msc). Дополнительные сведения см. в разделе .

  Для проверки отзыва сертификатов также можно использовать службу роли сетевого ответчика. Дополнительные сведения о сетевом ответчике см. в разделе .

Работают в Windows еще с версии 2000. ADCS позволяют выдавать и обслуживать цифровые сертификаты на основе ключей.

Любой сертификат представляет собой пару закрытого и открытого ключа. Закрытый ключ – приватная информация, идентифицирующая владельца, требующая защиты и не подлежащая распространению. Открытый ключ – доступная любому часть, использующаяся для проверки

На практике сертификаты применяются для:

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

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

Шифрования каналов – клиент шифрует пакеты публичным ключом сервера, таким образом только сервер, обладающий приватным (закрытым) ключом сможет расшифровать информацию от клиента.

Шифрование данных — два сотрудника, обменявшись открытыми (публичными) ключами, могут шифровать с их помощью файлы. Таким образом, расшифровать файл сможет только владелец приватного ключа. Или другой пример: для шифрования диска система использует публичный ключ, в то время как приватный хранится на флешке, без которой невозможно дешифрование.

За 17 лет службы сертификации конечно же модернизировались. Последние серьезные изменения в ADCS были внесены в версиях Windows 2012 и 2012 R2 . Наиболее важные из них:

• Поддержка модуля политики для службы регистрации сертификатов для сетевых устройств
• Аттестация ключей доверенного платформенного модуля (TPM)
• Windows PowerShell для служб сертификатов
• Поддержка обновления сертификата с прежним ключом
• Поддержка международных имен доменов

Простейшая архитектура Certificate services состоит из 2х серверов: корневого и выдающего. Помимо этого в инфраструктуре наверняка присутствует домен-контроллер, который может быть использован, как точка распространения сертификатов. Также для этих целей желательно иметь сервер с ролью Web. В прочем этот функционал может быть настроен на сервере с ролью выдающего центра сертификации.

Для того, чтобы службы сертификации заработали в вашей инфраструктуре необходимо настроить:

Корневой сервер сертификации. Несет функции инстанции, которой мы безоговорочно доверяем. Корневой сервер сертификации выдает сертификат для подписи выдающего сервера сертификации. После генерации доверенного корневого сертификата и CRL этот сервер рекомендуется выключить и (слава богу используется виртуализация) сложить в сейф.

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

Сертификаты, которыми подписаны центры сертификации, а также списки отозванных сертификатов имеют срок жизни, по истечении которого должны быть обновлены. Обновление CRL выдающего сервера происходит автоматически, в то время как обновление CRL корневого центра сертификации нужно проводить вручную (по умолчанию – раз в пол года). Для этого необходимо:

1. включить корневой центр сертификации
2. обновить CRL
3. опубликовать полученный CRL на всех точках проверки отозванных сертификатов.

После этого обычно выполняются другие процедуры обслуживания сервера. Такие как, установка обновлений и резервное копирование. После чего сервер выключается до следующего обновления CRL или другой потребности его запуска.

Все операции по управлению сервисом выполняются из нескольких консолей:

А также с помощью PowerShell и утилиты certutil, с возможностями которой можно ознакомится, набрав certutil /help в командной строке Windows.

В частности с помощью командной строки можно публиковать сертификаты и списки отозванных сертификатов в базе Active Directory. Также через службы Active Directory Domain Services (а именно через групповые политики) можно настроить распространение сертификатов: например, добавление сертификата корневого центра сертификации в Trusted certificates рабочих станций организации.

Помимо того, что сертификат содержит пару закрытого и открытого ключа, в нем также хранится служебная информация, в том числе о том, кому и когда выдан сертификат, алгоритмах генерации длине ключа и пр. Сертификат генерируется по шаблону, который должен быть опубликован уполномоченным администратором. По умолчанию Active Directory Certificate Services имеют набор заготовок шаблонов для различных сервисов (Web-server, Exchange server, RDP Gateway server и пр), на базе которых можно также создавать шаблоны под собственные нужды.

Как видно из скриншота сертификаты широко применяются для защиты информации и информационных каналов. Наиболее часто используются:

• Сертификаты для веб ресурса.
• Сертификаты для защиты соединения.
• Сертификаты для цифровой подписи.

Наша компания готова помочь в настройке и администрировании служб сертификации на базе Microsoft Windows 2016 и более ранних версий, а также в выполнении любых работ по защите веб ресурсов, соединений и данных с использованием сертификатов. Обращайтесь,

Нет похожих статей.

Этой небольшой статьей я планирую начать цикл статей, посвященных настройке Windows Server 2008 R2 . Планируется несколько статей — пошаговых мануалов, таких как миграция с Exchange 2003 на Exchange 2010, публикация сервисов Exchange на TMG, настройка Remote Desktop Services и опять же публикация их на TMG и т.п.

Мы рассмотрим установку служб сертификации Active Directory (AD CS), так как они мне понадобятся во всех последующих статьях.

Исходные данные : как всегда, имеется в наличии домен testcompany.local , контроллер домена dc01 под управлением Windows Server 2008 R2, единственный, для тестовой среды достаточно.

Будет рассматриваться упрощенная модель развертывания служб сертификации, достаточная для большинства небольших и средних организаций, с установкой единственного центра сертификации с типом Enterprise. Для развертывания инфраструктуры с подчиненными центрами сертификации эта статья не подходит. Впрочем, если всё же захочется, в Microsoft Technet всё есть, дерзайте. Также можно ознакомиться со статьей на сайте Вадима Поданса: Обсуждение схем иерархии Certification Authority .

В тестовой среде я буду устанавливать службы сертификации (AD CS) на контроллер домена, dc01 , в реальной же сети, есть варианты. Если поставить на контроллер домена, то корневой сертификат автоматом распространится на все компьютеры домена без каких-либо усилий с вашей стороны. На отдельном сервере придется публиковать его в AD. Редакцию лучше выбрать Windows Server 2008 R2 Enterprise Edition, в которой можно будет создавать свои шаблоны сертификатов, а также там присутсвуют другие возможности, недоступные в редакции Standard. Различия можно увидеть по этой ссылке: http://technet.microsoft.com/en-us/library/cc755071.aspx . Не всем это правда будет нужно, но тем не менее, всегда лучше иметь больше возможностей, чем меньше 🙂

Запускаем Server Manager > Roles > Add Roles. Запустится визард, в нем на шаге Select Server Roles ставим галку напротив строчки Active Directory Certificate Services и нажимаем кнопку Next:

На следующем шаге Introduction to Active Directory Certificate Services внимательно читаем, что там написано и нажимаем Next.

На шаге Select Role Services дополнительно ставим галку Certification Authory Web Enrollment, остальные компоненты нам пока не понадобятся:

Появится окно с компонентами, которые необходимо добавить для этой роли, в нем нажимаем Add Required Role Services:

Следующий шаг — Specify Setup Type — выбор типа Certificate Authority, выбираем Enterprise, как планировали выше и нажимаем Next:

Следующий шаг — Specify CA Type — выбор корневого или подчиненного CA, выбираем корневой естественно, нажимаем Next:

Далее на шагах Setup Privat Key и Criptography соглашаемся с значениями по умолчанию и переходим к шагу Configure CA Name . Здесь задаем понятное имя нашего корневого центра сертификации, в данном случае TestCompany Root CA:

На шаге Set Validate Period задаем срок действия сертификата корневого CA, в моем примере можно согласиться с значением по умолчанию в 5 лет, в производственной среде можно сделать побольше, лет 10-15:

На всех дальнейших шагах соглашаемся с значениями по умолчанию, нажимаем везде Next и на последнем шаге Install: