Руководство по центрам сертификации

 

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

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

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

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

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

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

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

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

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

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

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

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

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0

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

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

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

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

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

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

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

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

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

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

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

Выбор типа ЦС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поставщик служб шифрования	Длины ключей	Хеш-алгоритм
Microsoft Base Cryptographic Provider версии 1.0	512 1024 2048 4096	SHA1 MD2 MD4 MD5
Microsoft Base DSS Cryptographic Provider	512 1024	SHA1
Microsoft Base Smart Card Crypto Provider	1024 2048 4096	SHA1 MD2 MD4 MD5
Microsoft Enhanced Cryptographic Provider версии 1.0	512 1024 2048 4096	SHA1 MD2 MD4 MD5
Microsoft Strong Cryptographic Provider	512 1024 2048 4096	SHA1 MD2 MD4 MD5
RSA#Microsoft Software Key Storage Provider	512 1024 2048 4096	SHA1 SHA256 SHA384 SHA512 MD2 MD4 MD5
DSA#Microsoft Software Key Storage Provider	512 1024 2048	SHA1
ECDSA_P256#Microsoft Software Key Storage Provider	256	SHA1 SHA256 SHA384 SHA512
ECDSA_P384#Microsoft Software Key Storage Provider	384	SHA1 SHA256 SHA384 SHA512
ECDSA_P521#Microsoft Software Key Storage Provider	521	SHA1 SHA256 SHA384 SHA512
RSA#Microsoft Smart Card Key Storage Provider	1024 2048 4096	SHA1 SHA256 SHA384 SHA512 MD2 MD4 MD5
ECDSA_P256#Microsoft Smart Card Key Storage Provider	256	SHA1 SHA256 SHA384 SHA512
ECDSA_P384#Microsoft Smart Card Key Storage Provider	384	SHA1 SHA256 SHA384 SHA512
ECDSA_P521#Microsoft Smart Card Key Storage Provider	521	SHA1 SHA256 SHA384 SHA512

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

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

• DBDirectory

• DBLogDirectory

• DBSystemDirectory

• DBTempDirectory

Настройка ЦС

После установки корневого или подчиненного ЦС необходимо настроить расширения доступа к информации о центрах сертификации (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. На вкладке Расширение свойств ЦС поддерживаются переменные в скобках. В приведенной ниже таблице сопоставляются переменные из разных интерфейсов и описываются их значения.

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

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

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

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

Имя параметра в интерфейсе	Параметр Windows PowerShell	Значение в Certutil
Включать в AIA-расширение выданных сертификатов	-AddToCertificateAia	2
Включать в расширения протокола OCSP	-AddToCertificateOcsp	32

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

• Доменное имя — corp.contoso.com.

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

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

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

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

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

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

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

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

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

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

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

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

• https://www.contoso.com/pki/\<имя_DNS-сервера>_<имя_ЦС><имя_сертификата>.crt

  • Включать в AIA-расширение выданных сертификатов

• file://\\App1.corp.contoso.com\pki\<имя_DNS-сервера>_<имя_ЦС><имя_сертификата>.crt

• ldap:///CN=<усеченное_имя_ЦС>,CN=AIA,CN=Public Key Services,CN=Services,<контейнер_конфигураций><класс_объектов_ЦС>

  • Включать в AIA-расширение выданных сертификатов

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

Для настройки расширения AIA в данном сценарии можно использовать указанные ниже команды Windows PowerShell.

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia https://www.contoso.com/pki/%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia file://\\App1.corp.contoso.com\pki\%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

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

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

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:https://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"

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

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

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

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

Если разрешена публикация разностных списков отзыва сертификатов на веб-сервере 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. Дополнительную информацию можно найти в статье : для публикации разностных списков отзыва сертификатов на веб-сервере должны быть разрешены URI, содержащие символ "+".

В примерах публикации расширения 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 по данному адресу

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

• https://www.contoso.com/pki/\<имя_ЦС><суффикс_имени_CRL><разностные_CRL_разрешены>.crl

  • Включить в CRL. Клиенты используют эти данные для поиска расположений разностных CRL.

  • Включать в CDP-расширение выданных сертификатов

• file://\\App1.corp.contoso.com\pki\<имя_ЦС><суффикс_имени_CRL><разностные_CRL_разрешены>.crl

  • Опубликовать CRL по данному адресу

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

• ldap:///CN=<усеченное_имя_ЦС><суффикс_имени_CRL>,CN=<краткое_имя_сервера>,CN=CDP,CN=Public Key Services,CN=Services,<контейнер_конфигураций><класс_объектов_CDP>

  • Включить во все CRL. Указывает место публикации в Active Directory при ручной публикации.

  • Включать в CDP-расширение выданных сертификатов

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

Для настройки расширения CDP в данном сценарии можно использовать указанные ниже команды Windows PowerShell.

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl
Add-CACRLDistributionPoint -Uri file://\\App1.corp.contoso.com\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10" -AddToCrlCdp -AddToCertificateCdp

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

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

certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:https://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"

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

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

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

Команда	Описание
Certutil -CAInfo	Показывает состояние имен, языкового стандарта, идентификаторов объектов и списков отзыва сертификатов для ЦС.
Certutil -getreg	Выводит конфигурацию реестра для ЦС.
Certutil -ADCA	Проверяет конфигурацию ЦС предприятия.

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

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

Связанное содержимое

• Форум по обеспечению безопасности Windows Server

• Инфраструктура открытых ключей (PKI) служб сертификатов Active Directory: вопросы и ответы

• Справочная документация и библиотека по Windows PKI

• Блог о Windows PKI