Windows Server. Создание автономного центра сертификации

Служба сертификации Active Directory

Служба сертификации Active Directory (AD CS) в Windows Server 2008 R2

Windows Server 2008 R2 содержит встроенный центр сертификации (СА), называе­мый службой сертификации Active Directory (Active Directory Certificate Services - AD CS). Первый вариант AD CS появился в Windows Server 2008, а раньше эта технология называ­лась просто службой сертификации (Certificate Services). AD CS может использоваться для создания сертификатов и последующего управления ими и отвечает за обеспечение их под­линности. Зачастую AD CS в Windows Server 2008 R2 используется без особой необходимости проверки сертификатов организации какой-либо независимой стороной. Поэтому если сертификаты требуются только для участников внутри организации, часто применяется развертывание самостоятельного СА для шифрования сетевого трафика. Широко исполь­зуются и сторонние центры сертификации наподобие VeriSign, но они требуют дополни­тельного вложения средств.

Хотя в новом названии службы сертификации Windows упоминается Active Directory, сле­дует понимать, что для работы AD CS совсем не требуется интеграция с существующей средой леса доменной службы Active Directory (Active Directory Domain Services (AD DS)). Обычно это все же так, но важно понимать, что AD CS не зависит от структуры леса AD DS.

В Windows Server 2008 R2 добавлено несколько новых возможностей AD CS:

  • Веб-служба развертывания сертификатов и веб-служба политики развертыва­ния сертификатов. Это наиболее значительное усовершенствование позволяет раз­вертывать сертификаты непосредственно по протоколу HTTP и дает возможность клиентам, не принадлежащим домену или подключенным к Интернету, обращаться к серверу СА и запрашивать сертификаты.
  • Улучшенная поддержка объемных СА, используемых для NAP. В Windows Server 2008 R2 повышена скорость работы AD CS с базой данных, когда возникают ситуации массированной работы, как с NAP.
  • Поддержка развертывания сертификатов между лесами. AD CS в Windows Server 2008 R2 позволяет консолидировать СА между несколькими лесами.

Применимо к: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). Дополнительные сведения см. в разделе .

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

Как известно, сертификаты нужны для надежной аутентификации, создания 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.

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

Установка самоподписанных сертификатов весьма частая задача для системного администратора. Обычно это делается вручную, но если машин не один десяток? И как быть при переустановке системы или покупке нового ПК, ведь сертификат может быть и не один. Писать шпаргалки-напоминалки? Зачем, когда есть гораздо более простой и удобный способ - групповые политики ActiveDirectory. Один раз настроив политику можно больше не беспокоится о наличии у пользователей необходимых сертификатов.

Сегодня мы рассмотрим распространение сертификатов на примере корневого сертификата Zimbra, который мы экспортировали в . Наша задача будет стоять следующим образом - автоматически распространять сертификат на все компьютеры входящие в подразделение (OU) - Office . Это позволит не устанавливать сертификат туда, где он не нужен: на севера, складские и кассовые рабочие станции и т.д.

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

После чего перетащите политику на контейнер Office , что позволит применить ее к данному подразделению.

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

Политика создана, теперь самое время проверить правильность ее применения. В оснастке Управление групповой политикой выберем Моделирование групповой политики и запустим по правому щелчку Мастер моделирования .

Большинство параметров можно оставить по умолчанию, единственное что следует задать - это пользователя и компьютер для которых вы хотите проверить политику.

Выполнив моделирование можем убедиться, что политика успешно применяется к указанному компьютеру, в противном случае раскрываем пункт Отклоненные объекты и смотрим причину по которой политика оказалась неприменима к данному пользователю или компьютеру.

После чего проверим работу политики на клиентском ПК, для этого обновим политики вручную командой:

Gpupdate

Теперь откроем хранилище сертификатов. Проще всего это сделать через Internet Explorer : Свойства обозревателя - Содержание - Сертификаты . Наш сертификат должен присутствовать в контейнере Доверенные корневые центры сертификации .

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

В предыдущей статье «Узел сеансов удаленных рабочих столов в Windows Server 2012 R2» было рассказано о настройке удаленных рабочих столов на основе сеансов. В этом случае клиенту необходимо зайти на страницу веб-доступа по защищенному протоколу https.

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

Чтобы https-страница открывалась без упоминаний об ошибке сертификата, необходимо на сервере с установленной ролью веб-доступа получить ssl-сертификат. Сделать этого можно абсолютно бесплатно при помощи Службы сертификации Active Directory, про установку которой было написано в статье «Установка Службы сертификации Active Directory (AD CS)».

Напомню, о каких серверах пойдет речь: FS-01 (сервер со службой сертификации AD CS) и TS-00 (сервер с ролью веб-доступа служб удаленных рабочих столов).

1. Настройка Центра сертификации

На сервере FS-01 открываем оснастку «Центр сертификации»:

Выбираем центр сертификации (в моем случае с названием sektor-gaza-FS-01-CA-2), кликаем правой кнопкой мыши на разделе «Шаблоны сертификации» и далее выбираем пункт «Управление»:

Откроется Консоль шаблонов сертификатов:

В области «Отображаемое имя шаблона» кликаем правой кнопкой мыши на «Веб-сервер» и далее из контекстного меню выбираем пункт «Свойства»:

В окне «Свойства: Веб-сервер» переходим на вкладку «Безопасность» и для группы «Прошедшие проверку» ставим галочку «Разрешить» напротив пункта «Заявка»:

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

2. Настройка веб-сервера IIS

На сервере TS-00 открываем оснастку «Диспетчер служб IIS»:

Нажимаем на названии сервера и двойным кликом левой кнопкой мыши запускаем «Сертификаты сервера»:

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

Чтобы создать ssl-сертификат, которому будут доверять другие клиенты вашей доменной сети, в области «Действия» выберите пункт «Создать сертификат домена».

Откроется окно создания сертификата домена:

Заполните все доступные поля и нажмите «Далее». Поскольку это будет ваш внутренний сертификат от Центра сертификации AD CS, то в качестве значений можно использовать любые данные. Но в поле «Полное имя» лучше указать название вашего сайта (мой сайт доступен по адресу , и в качестве имени я указал «TS-00»), т. к. в противном случае браузер может возвращать ошибку о несоответствии имени сайта, на который выдан сертификат.

Выбор Центра сертификации:

В этом окне в поле «Локальный центр сертификации» необходимо указать имя вашего Центра сертификации AD CS и имя сервера (с установленной Службой сертификации), а в поле «Понятное имя» укажите простое и короткое имя Центра сертификации. После нажимаем кнопку «Готово». Обратите внимание, что в первом поле присутствует символ «\», разделяющий имя центра сертификации и имя сервера. Также можно воспользоваться кнопкой «Выбрать» и далее указать необходимый Центр сертификации, но данная кнопка не всегда бывает доступной.

Через несколько секунд ssl-сертификат будет создан, и откроется окно «Сертификаты сервера»:

Теперь здесь отображается только что созданный сертификат. Как видим, его поставщиком является Центр сертификации AD CS sektor-gaza-FS-01-CA-2, т. е. все прошло успешно.

Переходим на сервер FS-01 в оснастку «Центр сертификации» и открываем раздел «Выданные сертификаты»:

Здесь также можно увидеть созданный ssl-сертификат для сервера TS-00.

Возвращаемся на сервер TS-00 в оснастку «Диспетчер служб IIS», открываем список «Сайты, нажимаем на названии нашего сайта (в моем случае это «Default Web Site») и в области «Действия» выбираем пункт «Привязки»:

В окне «Привязки сайта» выбираем протокол «https» и нажимаем кнопку «Изменить»:

В окне «Изменение привязки сайта» открываем раскрывающий список «SSL-сертификат» и выбираем наш созданный сертификат (в моем случае это «FS-01-CA-2»):

Нажимаем «ОК» и в окне «Привязки сайта» выбираем «Закрыть».

Теперь необходимо перезапустить веб-сайт:

Кликаем правой кнопкой мыши на названии нашего сайта, из контекстного меню выбираем пункт «Управление веб-сайтом» и далее нажимаем «Перезапустить».

3. Проверка правильности установки ssl-сертификата

Чтобы проверить, правильно ли установлен ssl-сертикат, можно зайти на страницу веб-доступа (в моем случае это

Читайте также