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

Диспозиция:

Сервер Windows Server 2008 R2 c установленной ролью Active Directory Certificate Service и наличием аппаратных проблем)

Новый сервер Windows Server 2012 R2.

Перенос сервиса сертификации Active Directory на Windows Server 2012 R2.

Для начала подготовим резервную копию текущего центра сертификации. Для этого в оснастке Certificate Authority через

все задачи выбираем Архивация ЦС

Указываем архивирование всех элементов ЦС и путь для резервной копии

Для защиты закрытого ключа и файла сертификата центра сертификации указываем пароль

Архивация центра сертификации выполнена

Кроме базы данных центра сертификации Microsoft необходимо выгрузить и настройки, которые хранятся в реестре.

Для этого нужно выгрузить ветку

Итог должен выглядеть так:

После проведения подобных манипуляция можно остановить службу сервера сертификатов и в последствии удалить центр сертификации со старого сервера. Данный процесс описывать большого смысла не имеет. Идем дальше.

В промежуточном результате мы имеем экспортированную конфигурацию служба сертификатов Active Directory и желание его «реанимировать» на новом сервере.

Продолжим, установим cлужбу сертификатов Active Directory c необходимыми компонентами. Та этом вопросе останавливаться долго не будем, полагаю тут все просто:

Выбор необходимых ролей

Непосредственно процесс установки

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

Нажимаем «Настроить службы сертификатов Active Directory..»

В открывшемся окне выбираем учетную запись от имени которой будет производится настройка сервера. Роль должна входить в группу «Администраторы предприятия»

На следующем шаге указываем какие роли мы будем настраивать

В следующем окне выбираем “Корневой ЦС” в качестве типа ЦС и нажмите “ Далее” для продолжения.

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

На этом этапе указываем путь к выгруженному сертификату со старого центра сертификации и пароль указанный при экспорте к нему.

После импорта то мы увидим наш сертификат

На следующем этапе определяем путь к базе данных сертификата. Тут я оставил все как есть, по умолчанию. Далее.

Итоговая проверка всех указанных выше параметров для настройки

Процесс настройки завершен.

После настройки параметров ЦС, преступим у его восстановлению. На созданном сервере сертификатов выбираем «Восстановление ЦС»

Выбираем элементы, и указываем путь к папке в которую произведен экспорт

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

Восстановление завершено. Осталось только восстановить параметры, которые хранятся в реестре. Для этого как раз мы и экспортировали ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

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

Осталось проверить работу нового центра сертификации. Как видим, все выданные сертификаты перенесены.

Новый Web сервер работает выдачи сертификатов работает.

Итог: Сервис сертификации Active Directory успешно перенесен на новый сервер, при этом как мы видели, произошла и миграции в рамках операционной системы 2008R2 -> 2012R2.

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

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

Служба сертификации Active Directory (AD CS) является очень удобным и полезным инструментом в доменной сети. Данный компонент входит в состав Windows Server 2012 R2, позволяет бесплатно выдавать ssl-сертификаты внутри вашего домена и управлять ими. Такие сертификаты могут понадобиться при работе с почтовым сервером Microsoft Exchange, сеансами удаленных рабочих столов и т. д.

Службу AD CS не рекомендуется устанавливать на контроллер домена. В данной статье в качестве примера будут использоваться 3 сервера под управлением операционной системы Windows Server 2012 R2: DC-01 (контроллер домена), FS-01 (сервер, на который будет установлена служба AD CS) и TS-00 (сервер, для которого мы будем получать ssl-сертификат).

1. Заходим в Диспетчер серверов на сервере FS-01:

Выбираем пункт «Управление» и далее «Добавить роли и компоненты».

2. Откроется Мастер добавления ролей и компонентов. На вкладке «Тип установки» выбираем пункт «Установка ролей и компонентов»:

Нажимаем «Далее».

3. На вкладке «Выбор сервера» отмечаем пункт «Выберите сервер из пула серверов» и в области «Пул серверов» выбираем конечный сервер для установки Active Directory Certificate Services:

В моем случае это локальный сервер FS-01 с ip-адресом 192.168.1.22. Нажимаем «Далее».

4. На вкладке «Роли сервера» выбираем роль «Службы сертификатов Active Directory»:

В новом окне предстоит добавить компоненты, необходимые для Службы сертификатов Active Directory:

Ставим галочку напротив пункта «Включить средства управления (если применимо)» и нажимаем кнопку «Добавить компоненты». После этого вновь откроется Мастер добавления ролей и компонентов на вкладке «Роли сервера», где необходимо нажать кнопку «Далее».

5. На вкладке «Компоненты» оставляем все настройки по умолчанию и нажимаем «Далее»:

6. Информационная вкладка Службы сертификации Active Directory:

На данной вкладке представлены краткие сведения о Службах сертификации Active Directory. В частности сообщается о том, что нельзя менять имя и параметры домена компьютера, на котором установлена AD CS. После прочтения информации нажимаем «Далее».

7. На вкладке «Службы ролей» выбираем службу «Центр сертификации»:

Нажимаем «Далее».

8. На вкладке «Подтверждение» можно ознакомиться со списком всех служб ролей и компонентов, которые будут установлены на данном сервере:

Для изменения настроек воспользуйтесь кнопкой «Назад». Если все правильно, нажимаем кнопку «Установить». Перед установкой рекомендую активировать пункт «Автоматический перезапуск конечного сервера, если потребуется», чтобы при необходимости сервер смог автоматически перезагрузиться в процессе установки службы сертификации AD CS.

9. Начнется установка службы сертификации AD CS и других служб ролей и компонентов:



Дождитесь завершения установки. Данное окно можно закрыть.

10. Когда установка AD CS завершится, перейдите в Диспетчер серверов, нажмите на «флажок» с восклицательным знаком в желтом треугольнике и выберите пункт «Настроить службы сертификатов Active Directory»:

11. Откроется окно «Конфигурация службы сертификатов Active Directory». На вкладке «Учетные данные» укажите учетные данные пользователя для настройки служб роли:

Обратите внимание, что для установки служб ролей «Автономный центр сертификации», «Служба регистрации в центре сертификации через Интернет» и «Сетевой ответчик» пользователь должен быть членом локальный группы «Администраторы». Для установки служб ролей «Центр сертификации предприятия», «Веб-служба политик регистрации сертификатов», «Веб-служба регистрации сертификатов» и «Служба регистрации на сетевых устройствах» пользователь должен быть членом доменной группы «Администраторы предприятия». Выберите пользователя при помощи кнопки «Изменить» и нажмите «Далее».

12. Выбор службы роли для настройки (Центр сертификации):

На вкладке «Службы ролей» выбираем «Центр сертификации» и нажимаем «Далее». Обратите внимание, что необходимо сначала настроить службу роли «Центр сертификации», а затем другие службы, т. е. одновременный выбор нескольких служб на данной вкладке не поддерживается.

13. Вариант установки Центра сертификации:

На вкладке «Вариант установки» выберите пункт «ЦС предприятия» и нажмите «Далее».

14. Тип Центра сертификации:

На вкладке «Тип ЦС» выбираем пункт «Корневой ЦС» и нажимаем «Далее».

15. Тип закрытого ключа:

На вкладке «Закрытый ключ» выбираем пункт «Создать новый закрытый ключ» и нажимаем «Далее».

16. Параметры шифрования:

На вкладке «Шифрование» предлагаю параметры «Поставщик служб шифрования» (RSA#Microsoft Software Key Storage Provider) и «Длина ключа» (2048) оставить по умолчанию, а значение «Хэш-алгоритма для подписывания сертификатов, выдаваемых этим ЦС» указать «SHA256». Нажимаем «Далее».

17. Имя Центра сертификации:

На вкладке «Имя ЦС» можно указать общее имя для этого центра сертификации, суффикс различающегося имени и предпросмотр различающегося имени. В моем случае все значения остаются по умолчанию. Нажимаем «Далее».

18. Срок действия сертификата:

На вкладке «Срок действия» необходимо указать период действия сертификата для данного Центра сертификации. Обратите внимание, что срок действия сертификата для Центра сертификации должен превышать срок действия сертификатов, которые он будет выдавать. Нажимаем «Далее».

19. Расположение базы данных сертификатов:

На вкладке «База данных сертификатов» укажите расположение базы данных сертификатов и журнала базы данных сертификатов. В моем случае значения остаются по умолчанию. Нажимаем «Далее».

20 Подтверждение установки Центра сертификации:

На данной вкладке можно ознакомиться со всеми выбранными настройками и при необходимости их изменить, воспользовавшись кнопкой «Назад». Если все правильно, нажимаем «Настроить».

21. Настройка Центра сертификации выполнена успешно:

Если процесс завершился без ошибок, нажимаем кнопку «Закрыть».

22. Переходим в Диспетчер серверов:

Установка Службы сертификации Active Directory (AD CS) выполнена успешно.

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

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

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

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

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

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

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

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

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

Gpupdate

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

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

• Перевод

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

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

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

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

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

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


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


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

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

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

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


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


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


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

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

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


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


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


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


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

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

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


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


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


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


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

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

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


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


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


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


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


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


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


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


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


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


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


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


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


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

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

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


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


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


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


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


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

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

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


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

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

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


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

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

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

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