В автономном центре сертификации windows сервер не используется

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

ЦС предприятия

• Требует наличия ActiveDirectory
• Автоматическое подтверждение сертификатов
• Автоматическое развертывание сертификатов
• Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

• Не требует наличия ActiveDirectory
• Ручное подтверждение сертификатов
• Отсутствие возможности автоматического развертывания
• Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

Windows Server 2008 R2

Проверка работы ЦС

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Всем привет, с вами Искандер Рустамов, младший системный администратор Cloud4Y. Сегодня мы будем покорять развертывание центра сертификации (ЦС). 

Из-за сложной геополитической обстановки резко усилился процесс импортозамещения, появилась необходимость в выстраивании инфраструктуры на базе государственных требований к решениям в области информационной безопасности. Одним из таких решений является организация доступа клиентов к веб-ресурсам через портал nGate по защищённому TLS соединению с использованием шифрования по ГОСТ криптопровайдера «КриптоПро». Для этого необходим собственный центр сертификации. 

В данной статье мы рассмотрим установку Standalone Center Authority на базе Windows Server 2019. Если вам будет интересно, могу описать процесс привязки нашего центра сертификации к порталу nGate (спойлер: на самом деле там нет ничего сложного). 

Вводные данные

КриптоПро NGate — это универсальное высокопроизводительное средство криптографической защиты сетевого трафика, объединяющее в себе функционал:

• TLS-сервера доступа к веб-сайтам;

• Сервера портального доступа;

• VPN-сервера.

NGate обладает широкими возможностями по управлению доступом удалённых пользователей как с обеспечением строгой многофакторной аутентификации, так и прозрачно, обеспечивая при этом гибкое разграничение прав доступа к ресурсам. КриптоПро NGate реализует российские криптографические алгоритмы, сертифицирован по требованиям к СКЗИ, имеет сертификаты ФСБ России по классам КС1, КС2 и КС3 и может использоваться для криптографической защиты конфиденциальной информации, в том числе персональных данных, в соответствии с требованиями российского законодательства по информационной безопасности.

Кроме того, NGate:

• Снижает нагрузку по обработке TLS-соединений с веб-серверов, позволяя им сосредоточиться на выполнении своих основных задач;

• Исключает необходимость установки на каждом веб-сервере отдельного СКЗИ и проведения исследований по оценке влияния ПО веб-серверов на СКЗИ.

Процесс настройки

Ранее я не сталкивался с центрами сертификациями. Поскольку ОС Windows Server мне ближе, решил развернуть ЦС с использованием Server Manager. Разворачивать контроллер домена не нужно, так как сертификаты будут выдаваться внешним пользователям. Соответственно, можно обойтись «автономным» центром сертификации, подробнее о нём расскажу позже. 

Перед развертыванием центра сертификации необходимо: 

• Установить СКЗИ КриптоПро CSP 5.0.12330:

• Установить КриптоПро ЭЦП Browser plug-in;

Инсталляцию производим через «Дополнительные опции»

1. Выбираем язык установки, уровень защиты КС1 (другие уровни защиты требуют дополнительных аппаратных средств защиты);

2. В разделе «Установка компонентов» проверяем, что добавлен «Криптопровайдер уровня ядра ОС»; (рис. 1)

Криптопровайдер уровня ядра ОС необходим для работы криптопровайдера
в службах и ядре Windows.

3.  В следующем окне оставляем пункты:

• Зарегистрировать считыватель «Реестр» (позволит сохранять контейнеры ключей в реестр);

• Усиленный контроль использования ключей;

• Не разрешать интерактивные сервисы Windows;

4. Также «КриптоПро» предложит добавить сертификаты своих центров сертификации;

5. Устанавливаем, перезагружаемся.

Установка центра сертификации (Standalone CA Windows Server 2019)

Непосредственно перед самой установкой коротко объясню особенности Standalone CA:

• Не интегрирован с Active Directory (а он нам и не нужен);

• Публикация сертификатов происходит через запрос на WEB-сайте. Путем автоматического или ручного подтверждения администратором ЦС (ЕМНИП, ЦС предприятия было добавлена такая возможность, не проверял её работу);

• Пользователь сам вводит идентификационную информацию во время запроса сертификата;

• Не поддерживает шаблоны сертификатов (из-за этого всплывут некоторые моменты, которые раскрою в процессе развертывания).

Начинаем:

1. Измените имя компьютера до установки роли, после это будет сделать невозможно. «Далее (Next)» (рис.2): 

2. Добавляем роль в «Диспетчере серверов» (Server Manager), «Далее (Next)» (рис. 3):

2.1. «Установка ролей и компонентов (Add roles and features wizard)». Нажимаем «Далее (Next)» — «Далее (Next)»;

2.2. «Тип установки: Установка ролей и компонентов (Installation type: Role-based or features-based installation». «Далее (Next)»;

2.3. «Выбор сервера (Server selection)». В нашем случае среди предложенных будет один сервер и имя компьютера. «Далее (Next)» (рис. 4);

2.4. «Роли сервера (Server roles). Здесь необходимо отметить две роли: Служба сертификатов Active Directory (Certificate Services Active Directory), Веб-сервер IIS (Web-server IIS);

Во всплывающем окне перечня нажимаем «Добавить компонент (Add features)» — «Далее (Next)»;

2.5. «Компоненты (Features) оставляем как есть — «Далее (Next)» ;

2.6. «Служба ролей (Role Services)» ЦС, необходимо выбрать:

• «Центр сертификации (Certification Authority)»,

• «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

Сетевой автоответчик (Online responder) добавим уже после развертывания ЦА, в противном случае могут возникнуть проблемы. 

2.7. В «Служба ролей (Role Services)» веб-сервера оставляем всё предложенное автоматически — «Далее (Next)»;

2.8. «Подтверждение (Confirmation).

На этом этапе запустится процесс установки роли.

3. После установки роли центра сертификации необходимо его настроить
(рис. 5). Выбираем: 

3.1. «Настроить службы сертификатов Active Directory (Configure Active Directory-Certificate Services)

3.2. Указываем учетные данные. Так как мы развертываем Standalone центр сертификации, не нужно состоять в группе «Администраторов предприятия (Enterprise Administrators)» — «Далее (Next)»;

3.3. Выбираем установленные службы ролей для настройки (Select role services to configure) ЦС: «Центр сертификации (Certification Authority)», «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

3.3.1. При выборе центра сертификации появится окно выбора ключевого носителя – КриптоПРО CSP, в качестве носителя для создания контейнера cngWorkAround используем хранилище ключей реестра Windows – Реестр. (рис. 6)

3.4. Указываем вариант установки ЦС (Specify the setup type of the CA):
Автономный центр сертификации (Standalone CA). «Далее (Next)»;

3.5. Указываем тип ЦС (Specify the type of CA) – Корневой ЦС (Root CA). «Далее (Next)»;

3.6. Необходимо создать закрытый ключ ЦС, чтобы он мог создавать и выдавать их клиентам. Для этого выбираем «Создать новый закрытый ключ (Create a new private key)».

В качестве поставщика службы шифрования выбираем один из трёх предложенных (не забывайте, что 2001 год уже устарел) Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider с длиной 512 и открытого ключа 1024 бита. (рис.7)

И обязательно подтверждаем: «Разрешить взаимодействие с администратором, если ЦС обращается к закрытому ключу (Allow administrator interaction when the private key is accessed by the CA)»;

3.7. Укажите имя центра сертификации и суффиксы различающего имени, данные суффиксы будут отображаться в составе сертификата в графе «Издатель (Issuer)».

СN = Certificate Name, O = Organization, L = Locale, S = Street, C = Country, E = E-mail; (рис.

3.8. Указываем необходимый «срок годности (validaty period)» корневого сертификата (в нашем случае было выбрано 15 лет). «Далее (Next)»;

3.9. Указываем расположение баз данных сертификатов (certificate database location). «Далее (Next)»;

3.10. В окне «Подтверждения (Confirmation) сверяем введённую информацию — «Настроить (Configure)»

3.11. Появится окно выбора носителя для создания контейнера нашего ЦС.

Где хранятся сами контейнеры ключей:

3.12. Далее откроется окно генерации начальной последовательности с помощью биологического ДСЧ. Для генерации случайной последовательности перемещайте указатель мыши или нажимайте различные клавиши. 

3.13. После введите пароль на доступ к закрытому ключу.

3.14. Далее появится окно результатов об успешной установке компонентов (рис.

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

Теперь необходимо выполнить некоторые настройки веб-сервера: прицепить сертификат (самоподписанный или выпущенный нашим же ЦА). Кстати, он уже работает. В качестве примера выпустим самоподписанный сертификат.

1. Откроем Диспетчер служб IIS (Manager IIS) — Сертификат сервера (Server Certificates) (рис. 9);

1.1. В открывшемся окне в панели «Действия (Actions)» выберем – «Создать самоподписанный сертификат (Create Self-Signed Certificate);

1.2. Выбираем тип «Личный (Personal) и указываем «Имя сертификата (Friendly Name)»

1.3. Теперь необходимо привязать этот сертификат для доступа по https к веб-серверу.

1.3.1. Переходим «Сайты (Sites)» — Default Web Site – Bindings – добавить (Add) — выбрать https – и выбрать самоподписанный SSL-сертификат.

Также сертификат вы можете выпустить следующим образом:
На этой же панели создайте запрос (Create certificate request) для выпуска сертификата через наш ЦА и дальнейшей его загрузки в IIS (Complete Certificate Request). Но это по желанию.

Пример запроса (request) для формирования запроса вручную

[NewRequest]
Subject="CN=ИмяСертификата ,O=Организация, L=Город, S=Улица, C=Страна, E=Почта"
ProviderName="Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
ProviderType=80
KeySpec=1
Exportable = TRUE
KeyUsage=0xf0
MachineKeySet=true
RequestType=Cert
SMIME=FALSE
ValidityPeriod=Years
ValidityPeriodUnits=2
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

В целом с веб-сервером мы закончили, в default web site вы можете увидеть, что были автоматически созданы virtual directory и applications «CertSrv». При желании можно создать отдельную виртуальную директорию под CRL’ки.

Установка сетевого ответчика (Online responder)

А вот мы и вернулись к установке автоответчика.

1. Добавляем роль в «Диспетчере серверов» (Server Manager) — «Далее (Next)» 

1.1. Установка ролей и компонентов (Add roles and features wizard)» — «Далее (Next)»;

1.2. «Роли сервера (Server roles), раскрываем роль: Служба сертификатов Active Directory (Certificate Services Active Directory); и устанавливаем галочку на «Сетевой ответчик» (Online Responder) 

1.3. Завершаем работу с мастером ролей и компонентов, путём односмысленных нажатий «Далее (Next)».

В IIS была добавлена Applications: ocsp. Только не пугайтесь, что сама по себе директория пустая. Так и должно быть. 

Нам осталось настроить центр сертификации и выпустить сертификат на OCSP.

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

1. В «Диспетчере серверов (Server manager)» — выбираем «Служба сертификации Active Directory (AD CS) – правой клавишей по вашему серверу и открываем: «Центр сертификации (Certification Authority).

1.1. Вы попали в оснастку управления центром сертификации: certsrv.

1.2. Выбираем ваш центр сертификации и открываем свойства (рис. 10):

1.3. Следующим важным шагом выступает настройка точек распространения CDP и AIA.

Authority Information Access (AIA) — содержит ссылки на корневой сертификат центра сертификации (Certification Authority)

CRL Distribution Point — содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. (рис. 11)

Мы используем веб-сервер, который доступен как внутри сети, так и из интернета (так как сертификаты могут использоваться пользователями интернета) по одному и тому же URL.

1.4. В разделе свойства переходим в «Расширения (Extensions):

 Удаляем ненужные точки распространения и оставляем локальную и внешнюю ссылку для CDP:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<CaName><CRLNAmeSuffix><DeltaCRLAllowed>.crl

Ставим галочки «Включить в CRL. Включить в CDP (Include in CRL. Include in the CDP)».

AIA:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

Ставим галочку: «Включать в AIA- расширение выданных сертификатов (Include in the AIA extension of issued certificates)»

OCSP:

https://<ip_address/dns_name>/ocsp

Ставим галочку: «Включать в расширение протокола OCSP (Include in the online certificate status protocol (OCSP) extension)»

В свойствах центра сертификации можно настроить автоматический выпуск сертификатов при поступившем запросе. Так вы исключаете возможность проверки указанных требуемых полей сертификатов. Для этого перейдите в «Модуль политик (Policy Module)» — «Свойства (Properties)» и выберите соответствующий пункт:

В первом случае сертификату присваивается режим ожидания, а одобрение выпуска сертификата остается за администратором;

Во втором случае из-за отсутствия шаблонов в Standalone CA сертификаты будут выпускаться автоматически. (рис. 12)

Да, центр сертификации уже функционирует и доступен по указанному dns-имени. Не забудьте открыть 80 и 443 порты для функционирования веб-сервера и online-reposnder’a, настройкой которого мы займёмся далее.

Проверить работу ЦС вы можете, перейдя в ChromiumGost или Internet Explorer или Edge (с поддержкой Internet Explorer(IE)): https://localhost/CertSrv.

При переходе по ссылке извне в IE необходимо добавить наш веб-сервер в «Надежные сайты (Trusted Sites)» в настройках в пункте «Безопасность».  Не забудьте, что должен быть установлен КриптоПро CSP, в ином случае при выпуске сертификата вам не будет доступен выбор ГОСТовского криптопровайдера (рис.13). 

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

Вернёмся в оснастку certsrv к нашему центру сертификации и настроим выпуск разностных CRL. Для этого необходимо открыть «Свойства (Properties)» раздела «отозванных сертификатов (Revoked Certificates)» (рис. 14).

1. Задаём «Интервал публикации CRL (CRL Publications interval)».

1.1. Включаем публикацию разностных CRL и задаём интервал.

Кажется, что все хорошо. Но есть один момент:

«ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:»

Выполните следующую команду в power shell:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Настройка OCSP — сетевого ответчика (Online responder)

Так как у Standalone центра сертификации нет шаблонов, нам необходимо вручную сформировать запрос и выпуск сертификата для конфигурации отзыва (Array configuration) в «Управление сетевым ответчиком (Online responder management). Для это используйте следующую конфигурацию для формирования запроса 

1.1. Создайте: ocsp.txt cо следующим внутренним содержанием:

[NewRequest]
Subject = "CN=Имя"
PrivateKeyArchive = FALSE
Exportable = TRUE
UserProtected = FALSE
MachineKeySet = TRUE
ProviderName = "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
KeyLength = 512
UseExistingKeySet = FALSE
RequestType = PKCS10
[ApplicationPolicyStatementExtension]
Policies = OCSPSigning
Critical = false
[OCSPSigning]
OID = 1.3.6.1.5.5.7.3.9
[EnhancedKeyUsageExtension]
OID="1.3.6.1.5.5.7.3.9"
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty

1.2. Откройте командную строку cmd. Перейдите в директорию с текстовым файлом или в будущем просто укажите полный путь при формировании запроса.

1.3. Узнаем, на какой срок сейчас выпускаются сертификаты. Для этого воспользуемся командой - certutil –getreg cavalidityperiodunits  

Результат — на рис. 15.

1.4. Изменим длительность выпуска сертификата:

 #Изменение выпуска сертификатов с текущего состояния на длительность в 5 лет
 certutil -setreg caValidityPeriodUnits 5 
 #Перезапуск сервера
 net stop certsvc 
 net start certsvc 

1.5. Сформируем запрос и выпустим сертификат для сетевого автоответчика (рис 16.):

#Конфигурирование запроса
 certreq -new <имя>.inf <имя>.req 
 
#Формирование запроса в ЦС
 certreq -submit <имя>.req
 
#Одобрение запроса (Можно руками через оснастку управления центром сертификации)
 certutil.exe -Resubmit "Цифра запроса" 

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

1.6. Экспортируем сертификат из центра сертификации и устанавливаем его в личные сертификаты локального компьютера.

1.6.1. После запроса сертификата открываем оснастку: Certificates (Run — MMC – Add or remove Snap-ins – Certificate),

1.6.2. Выбираем сертификат, выданный для сетевого ответчика. Нажимаем правой клавишей и открываем «Все задачи (Управление закрытыми ключами (All Tasks — Manage Private keys)». 

1.6.3. В открывшемся окне Permissions необходимо добавить в «Группы и пользователи (Group and Users):   Network Service и выдать право Read для этой учётной записи. (рис.16.1)

Это нужно сделать, так как служба OCSP работает от лица Network Service.

1.7. Далее переходим в настройки самого сетевого ответчика. (рис. 17)

1.8. Нам необходимо добавить «Конфигурацию отзыва (Revocation Configuration) – «Добавить»

2. Предстоит небольшой процесс настройки конфигурации отзыва.

2.1. «Далее».

2.2. Введите имя конфигурации – «Далее».

2.3. Выбираем второй пункт: «Выбрать сертификат в локальном хранилище сертификатов (Select a certificate from the local certificate store)» — «Далее».

2.4. В следующем окне нажимаем «Обзор (Browse)» и выбираем корневой сертификат нашего ЦА – «Больше вариантов (More choices)». (рис. 17) – «Далее».

2.5. В следующем окне выбираем «Выбрать сертификат подписи вручную (Manually a signing sertificate)

2.6. В последнем окне нажимаем «Поставщик (Provider)». Здесь необходимо указать источник, из которого будут браться базовые и разностные CRL. В нашем случае: http://localhost/CDP/CA-C4Y-VPN.crl (для базового) и  http://localhost/CDP/CA-C4Y-VPN+.crl (для разностного).

2.7. Осталось прицепить к нашей конфигурации выпускаемый ранее сертификат и проверить некоторые моменты.

2.7.1. Переходим в «Конфигурацию массива(array configuration)», выбираем конфигурацию и нажимаем «Назначить сертификат подписи (Assign Signing Certificate)». В появившемся окне нужно просто нажать «ОК».

2.7.2. Теперь необходимо «Обновить конфигурацию массива». Для этого выбираем «Конфигурация массива (Array configuration) – «Обновить (Refresh)»

2.7.3. После всех этих действий главное окно оснастки ocsp должно выглядеть так, как на рисунке 19.

В процессе самостоятельной настройки «сетевого ответчика» может возникнуть много вопросов, особенно если нет опыта работы с Standalone центром сертификации, в котором отсутствуют шаблоны, без которых можно обойтись, но пути становятся длиннее в исполнение.  Кстати говоря, если после прикрепления сертификата вы не получили заветное Working, то проверьте следующее (рис.20, 20.1):

Чтобы проверить работу центра сертификации и сетевого автоответчика, выпустите сертификат для конечного пользователя, установите его и экспортируйте в какую-нибудь директорию. А после воспользуйтесь утилитой: Certutil –url /patch/test.crt

Для подробного отчёта вы можете воспользоваться: certutil –verify –urlfetch /patch/test.crt

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

Дополнительно:

Что ещё интересного есть в блоге Cloud4Y

→ Малоизвестный компьютер SWTPC 6800

→ Сделайте Linux похожим на Windows 95

→ Бесплатные книги, полезные для IT-специалистов и DevOps

→ WD-40: средство, которое может почти всё

→ Игры для MS-DOS с открытым исходным кодом

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу.

Работа с корпоративными и автономными центрами сертификации CA

Центр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), является ключевым компонентом программного обеспечения инфраструктуры открытых ключей PKI (Public Pey Infrastructure) в среде Windows Server 2003. Центр CA принимает и обрабатывает запросы на получение сертификатов от пользователей PKI, идентифицирует эти запросы и проверяет их правомерность, выдает сертификаты в соответствии с политикой безопасности PKI, обновляет и аннулирует сертификаты, размещает сертификаты на различных узлах хранения, создает и публикует списки аннулированных сертификатов CRL (Сertificate Revocation Lists), а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL. Центр сертификации Windows 2003 CA может выполнять в безопасном режиме архивирование и восстановление секретных ключей. Чтобы оценить степень развития возможностей центров CA и PKI в среде Windows 2003, в этой статье мы рассмотрим компоненты архитектуры последней реализации служб Certificate Services, а также различия в процедурах развертывания корпоративного и автономного центра CA в среде Windows 2003.

Архитектура Windows 2003 Certificate Services. Архитектура Windows 2003 Certificate Services почти идентична той, которая использовалась Microsoft при реализации предыдущих версий названных служб. Основное различие состоит в том, что здесь Microsoft изменила структуру базы данных CA для реализации поддержки процедур архивирования и восстановления секретных ключей пользователей. Схема данной архитектуры показана на рисунке. Она включает в себя различные модули, базы данных, инструментальные средства администрирования, посредников и прикладной интерфейс CryptoAPI.

Рисунок. Архитектура CA

Модули. Сердцем Certificate Services является исполнительный механизм CA (certsrv.exe), который генерирует сертификаты и занимается управлением потоками сообщений между CA и другими компонентами служб Certificate Services. Серверный механизм CA взаимодействует с другими компонентами архитектуры через входные модули, модули политики и выходные модули.

Входной модуль принимает запросы на сертификаты, соответствующие формату криптографического стандарта открытых ключей № 10 (Public-Key Cryptography Standards, PKCS #10) или криптографического протокола управления, использующего синтаксис криптографических сообщений (Cryptographic Management protocol using Cryptographic Message Syntax, CMS). После приема запроса входной модуль помещает его в очередь для дальнейшей обработки модулем политики.

Модуль политики реализует правила политики центра CA в соответствии с установками, заданными администратором CA. Данный модуль передает исполнительному механизму CA информацию о структуре сертификата и принимает решение о выдаче сертификата, об отказе в его выдаче или о переводе запроса сертификата в режим ожидания. Для обновления информации о структуре сертификата модуль политики может обращаться к информации, хранящейся в каком-либо каталоге (например, Active Directory) либо в базе данных. Модуль политики, имеющийся в Windows 2003, называется certpdef.dll. Он поддерживает два типа политики: режим корпоративной политики и режим автономной политики. Эти режимы будут подробно рассмотрены ниже. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, следует запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Policy Module, показанной на экране 1.

Экран 1. Вкладка Policy Module в свойствах объекта

Выходные модули занимаются распространением и публикацией сертификатов, цепочек сертификатов, а также полных списков CRL и списков изменений CRL. Выходной модуль может записывать данные PKI в файл или передавать эти данные на удаленный узел, используя в качестве транспорта протокол HTTP или механизм удаленного вызова процедур RPC. Windows 2003 CA может поддерживать несколько выходных модулей, соответственно распространение и публикация сертификатов, цепочек сертификатов, полных cписков CRL и списков изменений CRL может выполняться одновременно в различные пункты назначения, включая каталоги LDAP, файловые ресурсы совместного пользования, каталоги Web и, наконец, ODBC-совместимые базы данных. По умолчанию в Windows 2003 CA входит выходной модуль, называемый certxds.dll, в котором реализована поддержка LDAP, FTP, HTTP и SMTP (в центрах Windows 2000 CA также поддерживаются все эти протоколы, за исключением последнего). Выходной модуль позволяет организовать автоматическую рассылку уведомлений от центра CA пользователям PKI и администраторам. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, нужно запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Exit Module, показанной на экране 2.

Экран 2. Вкладка Exit Module в свойствах объекта

Модули политики и выходные модули являются настраиваемыми и заменяемыми компонентами, поэтому любая организация может разработать на языках C++ или Visual Basic (VB) собственные модули и интегрировать их в архитектуру Certificate Services. Вся необходимая информация о процессах создания и замещения модулей имеется в комплекте документации Software Development Kit (SDK) для платформы Windows 2003.

Настройка модулей политики и выходных модулей осуществляется с помощью оснастки Certification Authority или через утилиту командной строки certutil.exe. Используя окно свойств объекта CA оснастки Certification Authority, можно добавлять выходные модули, настраивать расширения X.509 для сертификатов (например, определять узлы CDP (CRL Distribution Points) и узлы AIA (Authority Information Access)), а также настраивать параметры публикации для полных списков CRL и списков изменений CRL.

Базы данных. Центр CA имеет собственную базу данных, которая называется CAname.edb. В этой базе хранится информация по транзакциям, связанным с сертификатами, и собственно сертификаты. Здесь же хранятся архивированные секретные ключи. По умолчанию эта база данных хранится в каталоге %systemroot%system32certlog. Исполнительный механизм центра CA взаимодействует с базой данных с помощью файла certdb.dll. С появлением службы Windows 2000 Certificate Services изменилась используемая Microsoft технология работы с базами данных. Теперь здесь используется процессор баз данных Jet, что позволило сделать архитектуру Windows 2000 CA масштабируемой. Отметим, что аналогичная технология используется в базах данных AD и Microsoft Exchange Server.

Средства администрирования. В большинстве случаев для администрирования центра сертификации Windows 2003 CA используется оснастка Certification Authority, но это можно делать и с помощью утилиты командной строки certutil.exe. Оба средства взаимодействуют с исполнительным механизмом центра CA через библиотеку certadm.dll.

Посредники (intermediaries). Прикладные программы, помогающие клиенту корректно сформировать запрос сертификата, соответствующий формату PKCS #10 или CMS, называются посредниками или Registration Authorities (RA). Эти программы собирают специальные данные о пользователе и о запросе, которые необходимы для формирования корректного запроса сертификата. Например, любой запрос, направляемый корпоративному центру Windows 2003 CA, должен содержать ссылку на шаблон сертификата. Программы RA могут добавлять к запросу описание шаблона. Следует отметить, что эти программы используют определенные транспортные протоколы (например, HTTP и RPC), соответственно при этом и исполнительный механизм CA не должен использовать для работы другие типы транспорта.

Примерами посредников в Windows 2003 могут служить Web-страницы регистрации сертификатов, которые являются посредниками HTTP, а также оснастка Certificates консоли MMC, вызывающая мастер Certificate Request Wizard, которая играет роль RPC-посредника. При генерации секретных ключей на клиентской машине посредник HTTP обращается к библиотеке xenroll.dll, а при генерации секретных ключей на смарт-картах он использует библиотеку scenroll.dll. Посредник RPC для выполнения данных процедур вызывает библиотеку certcli.dll.

Прикладной интерфейс CryptoAPI. Для реализации всех криптографических функций, включая доступ и использование секретных ключей CA, центр сертификации задействует вызовы интерфейса CryptoAPI. Центр CA может хранить свой секретный ключ на жестком диске или на специальном аппаратном устройстве (например, на аппаратном модуле безопасности Hardware Security Module, HSM).

Установка Windows 2003 Certificate Services

При выполнении установки Windows 2003 Certificate Services может быть развернут корневой CA, подчиненный CA, корпоративный CA (интегрированный в AD) или автономный CA (не интегрированный в AD). Если служба Certificate Services устанавливается в корпоративном режиме, то в этом случае активируется аналогичный режим и для модуля политики центра Windows 2003 CA. Рассмотрим, чем отличаются корпоративный и автономный режимы. В таблице приведены сравнительные характеристики параметров, установленных по умолчанию, для автономного и корпоративного центров Windows 2003 CA.

При установке корпоративного центра CA та учетная запись, от имени которой выполняется установка, должна иметь привилегии Enterprise administrator и Domain administrator в корневом домене леса AD. Кроме того, сервер, на который устанавливается корпоративный CA, должен являться членом домена с функционирующей в нем службой AD. Если эти условия не выполнены, в CA installation Wizard будут недоступны возможности перехода в режим установки enterprise CA, соответственно развернуть центр CA можно будет только в автономном режиме.

Для того чтобы установить автономный центр CA, использовать AD необязательно. CA может устанавливаться как на автономный сервер, так и на сервер, входящий в домен, или на контроллер домена (DC). При такой установке не требуются и полномочия Enterprise administrator и Domain administrator, вполне достаточно прав локального администратора на данном сервере. Если при установке автономного центра CA все-таки использовать привилегии Enterprise administrator, в этом случае данный центр будет обладать некоторой дополнительной функциональностью. В частности, если пользователь с правами Enterprise administrator устанавливает автономный центр CA на сервер, входящий в состав домена, то в этом случае центр CA сможет публиковать выпущенные им сертификаты в AD.

Шаблоны сертификатов

Корпоративный центр CA использует шаблоны сертификатов, которые хранятся в структуре AD в контексте имен конфигурации. Шаблон определяет содержание и характеристики сертификата. Кроме того, с помощью шаблонов можно контролировать типы выпускаемых центром CA сертификатов и определять, какие пользователи могут запрашивать сертификаты у корпоративного центра CA, а также сертификаты какого типа могут им выдаваться. В инфраструктуре PKI среды Windows 2003 поддерживаются шаблоны сертификатов версии 2, которые, в отличие от шаблонов версии 1, являются полностью настраиваемыми. Настройка шаблонов осуществляется с помощью оснастки Certificate Templates консоли MMC.

Автономный центр CA не может использовать шаблоны сертификатов AD, в этом случае нельзя выполнять контроль типов сертификатов и пользователей, их получающих. По умолчанию автономный CA может выдавать только сертификаты, предназначенные для Web-аутентификации (Secure Sockets Layer, SSL; или Transport Layer Security, TLS), защиты электронной почты (Secure MIME, S/MIME), аутентификации сервера, цифровой подписи и для работы с протоколом IP Security (IPSec). Тем не менее можно модифицировать Web-интерфейс автономного центра CA (например, для того чтобы в списке отображались другие типы сертификатов) или запрашивать другие типы сертификатов, используя для этого значения специальных идентификаторов объектов (OID), которые хранятся в X.509-расширении сертификата Extended Key Usage.

Получение дополнительной информации при запросе сертификата

В процессе регистрации сертификата корпоративный центр CA ищет в структуре Active Directory информацию о пользователе, которая потребуется центру для заполнения определенных полей сертификата. Например, в поле X.509 SubjectAltName сертификата, выданного корпоративным центром CA, содержится ссылка на имя пользователя, определяющее его в AD, — User Principal Name (UPN). Если центр CA является автономным, он не имеет доступа к AD, поэтому информация, идентифицирующая пользователя и необходимая для получения сертификата с Web-сайта регистрации, должна вводиться пользователем вручную.

Как в корпоративных, так и в автономных центрах CA можно изменять установленные по умолчанию параметры, добавляемые центром CA к запросу сертификата. Это делается в процессе регистрации сертификатов путем редактирования файла certdat.inc, который находится в каталоге %systemroot%system32certsrv. Допускается изменение значений, установленных по умолчанию, для следующих параметров сертификата: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, и sDefaultCountry. Если привести значения этих параметров в соответствие с используемыми в организации наименованиями, можно будет сократить объем вводимой пользователем информации при запросе сертификата.

Автоматическая регистрация сертификатов

Центр CA корпоративного типа поддерживает технологию автоматической регистрации сертификатов, причем в Windows 2003 возможности данной технологии расширены и теперь распространяются как на пользовательские сертификаты, так и на сертификаты компьютеров. Более подробно эти вопросы рассматриваются в статье «Технология регистрации PKI сертификатов в Windows 2003 Server», опубликованной на сайте журнала Windows IT Pro/RE (http://www.osp.ru/win2000/safety/511_29.htm). Отметим, что если пользователь запрашивает сертификат от автономного центра CA, процесс регистрации должен быть запущен вручную, так как в данном случае какие-либо процедуры автоматизации отсутствуют.

Централизованное архивирование ключей

Корпоративный центр CA поддерживает механизмы централизованного архивирования ключей в базе данных CA, а автономный центр — нет. Возможности технологии архивирования и восстановления ключей CA более подробно обсуждаются в статье «Автоматическое архивирование и восстановление ключей в инфраструктуре Windows Server 2003 PKI», опубликованной в № 3 журнала Windows IT Pro/RE за 2006 г.

Утверждение запроса сертификата

В корпоративных центрах CA имеется поддержка механизмов автоматического и ручного утверждения запросов сертификатов. Для того чтобы настроить свойства режима обработки запросов сертификатов, можно воспользоваться либо свойствами корпоративного CA (через свойства модуля политики), либо свойствами шаблона сертификата версии 2 (с помощью вкладки Issuance Requirements окна свойств шаблона сертификата). Если настройка режима обработки запросов выполняется через свойства шаблона сертификата версии 2, то следует иметь в виду, что внесенные при этом изменения будут применены только к сертификатам того типа, который определяется данным шаблоном. Можно задать настройку, обязывающую администратора утверждать все поступающие запросы сертификатов вручную, независимо от установок в шаблоне сертификата. Для этого при настройке режима обработки запросов в свойствах CA нужно выбрать пункт Set the certificate request status to pending. The administrator must explicitly issue the certificate. Эти же пункты доступны и для автономного центра CA, с той лишь разницей, что автономный CA не может использовать шаблоны сертификатов, и, следовательно, не удастся настроить свойства обработки запросов для отдельного шаблона сертификата. В отличие от корпоративного центра, автономный CA при аутентификации поступающих запросов не использует внутренние механизмы аутентификации Windows, соответственно компания Microsoft не рекомендует устанавливать режим автоматического утверждения в свойствах обработки запросов для автономных центров CA. В этих случаях всегда следует оставлять установку, сделанную по умолчанию, в соответствии с которой каждый поступающий запрос сертификата должен утверждаться администратором вручную.

Опубликование сертификатов и списков CRL

Корпоративные центры CA хранят и публикуют сертификаты, а также полные списки CRL и списки изменений CRL в Active Directory. В то же время как корпоративные центры, так и автономные CA могут осуществлять размещение данных в файловой системе. Каждый размещенный в AD сертификат автоматически отображается на учетную запись того, кто его запрашивал. Служба Active Directory добавляет сертификат к многозначному атрибуту UserCertificate пользователя или объекта AD inetOrgPerson. Отметим, что не каждый выданный корпоративным центром CA сертификат автоматически публикуется в AD. Примерами сертификатов, которые не будут публиковаться автоматически, могут служить сертификат агента регистрации или сертификат для подписи списка CTL (certificate trust list).

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

Выбор типа CA, оптимального для решаемых задач

Итак, мы определили различия между корпоративным и автономным центром CA и теперь, на основании полученных знаний, можем выбирать конфигурацию центра CA, оптимальную для конкретной ситуации. Развертывание корпоративного центра Windows 2003 CA будет наилучшим решением для работы с сертификатами пользователей, имеющих учетные записи в AD и использующих протокол Kerberos для их аутентификации в инфраструктуре AD. Для внешних пользователей (например, пользователей из внешней сети, не имеющих учетных записей в инфраструктуре Windows внутренней сет) оптимальным решением будет использование автономного центра Windows 2003 СA.

Жан де Клерк — Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com

Таблица. Сравнение основных характеристик автономного и корпоративного центров сертификатов Windows2003 CA

В этой заметке мы рассмотрим процедуру миграции автономного центра сертификации (Standalone Certification Authority) с ОС Windows Server 2012 R2 на ОС Windows Server 2022 в рамках одного и того же виртуального сервера с переустановкой ОС. Одним из условий рассматриваемого примера будет сохранение имени сервера, хотя в целом данное условие не является обязательным.

Общий план действий будет следующий:

1. Создание резервной копии данных ЦС в Windows Server 2012 R2
2. Удаление служб ЦС из Windows Server 2012 R2
3. Переустановка ОС и установка служб ЦС в Windows Server 2022.
4. Первичная конфигурация ЦС
5. Восстановление базы данных и конфигурации ЦС из резервной копии

Шаг 1. Резервное копирование данных ЦС в Windows Server 2012 R2

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

На сервере с Windows Server 2012 R2 в оснастке управления Certification Authority (certsrv.msc) в основном контекстном меню для ЦС выбираем пункт «Back up CA…»

В открывшемся окне мастера резервного копирования включаем опции сохранения закрытого ключа и сертификата ЦС «Private key and CA certificate» и сохранения базы данных сертификатов «Certificate database and certificate database log«, а также указываем путь к защищённому от стороннего доступа каталогу для сохранения резервных копий.

Для защиты закрытого ключа в составе резервной копии зададим некий сложный пароль.

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

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

Backup-CARoleService -Path "C:CABackupPS" -Password (ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force) -KeepLog

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

Далее переходим в редактор системного реестра Windows и находим в нём ключ реестра, который хранит расширенные настройки ЦС:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration

Сохраняем содержимое этого ключа в *.reg файл, используя пункт меню «Export«.

Аналогичное действие можно выполнить с помощью командной строки и команды следующего вида:

reg export "HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration" "C:CABackupPSReg-CA1-WS2012R2.reg"

Сохраняем содержимое каталога с файлами резервной копии в защищённое стороннее место.

Шаг 2. Удаление служб ЦС из Windows Server 2012 R2

Данный шаг является опциональным для автономного ЦС, но будет желательным в случае, если выполняется переустановка/миграция доменного ЦС. В случае с доменным ЦС для удаления «Active Directory Certificate Services» нам потребуется права уровня Enterprise Admins.

Сначала деактивируем компоненту «Certification Authority Web Enrollment«, если она была установлена ранее. Если этого предварительно не сделать, то при попытке удаления ключевой компоненты «Certification Authority» мы получим ошибку с сообщением о том, что сначала необходимо удалить «Web Enrollment».

Uninstall-AdcsWebEnrollment -Force

Затем в оснастке «Server Manager» деактивируем компоненты роли «Active Directory Certificate Services«

Шаг 3. Переустановка ОС и установка служб ЦС в Windows Server 2022

После удаления роли AD CS, выводим сервер из домена, форматируем диск и начисто устанавливаем ОС Windows Server 2022. При настройке сервера (по условиям нашего примера) используем прежнее имя hostname.

После первичной настройки ОС и ввода в домен переходим в оснастку управления «Server Manager» и активируем ранее используемые компоненты «Certification Authority» и «Certification Authority Web Enrollment» для роли «Active Directory Certificate Services«

Шаг 4. Первичная конфигурация ЦС

После завершения процесса установки роли, переходим по ссылке «Configure Active Directory Certificate Services on the destination server«

Откроется мастер конфигурирования AD CS, в котором на шаге «Credentials» нужно указать учётные данные пользователя, от имени которого будет выполнять конфигурация ЦС. Для доменного ЦС требуются права уровня Enterprise Admins. А в нашем примере, для автономного ЦС, достаточно прав локального администратора сервера.

На шаге «Role Services» выбираем компоненты, которые хотим сконфигурировать.

На шаге «Setup Tyte» в нашем случае выбирается тип развёртывания – автономный ЦС: «Standalone CA«.

На шаге выбора типа ЦС в нашем случае выбирается «Root CA«, так как в нашем примере используется развёртывание автономного корневого ЦС.

На шаге «Private Key» выбираем пункт экспорта сертификата ЦС и ассоциированного с ним закрытого ключа ЦС: «Use existing private key» > «Select a certificate and use its associated private key«.

В окне импорта сертификата указываем путь к контейнеру *.p12 и пароль, который мы использовали ранее при создании резервной копии ЦС.

Убеждаемся в том, что сертификат ЦС подгрузился без ошибок.

На следующем шаге оставляем пути к БД в значениях по умолчанию и дожидаемся успешного завершения конфигурирования ЦС.

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

Шаг 5. Восстановление базы данных и конфигурации ЦС из резервной копии

Теперь настало время восстановить базу данных всех ранее выданных и отозванных сертификатов. Для этого в оснастке Certification Authority в основном контекстном меню для ЦС выбираем пункт «Restore CA…»

Перед началом работы мастера восстановления мы получим предупреждение о том, что в ходе восстановления служба сертификации будет будет остановлена.

В открывшемся окне мастера восстановления включаем опции восстановления закрытого ключа и сертификата ЦС «Private key and CA certificate» и восстановления базы данных сертификатов «Certificate database and certificate database log«, а также указываем путь к каталогу с созданной ранее резервной копией ЦС.

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

Мастер восстановления должен отработать без ошибок.

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

После этого в оснастке Certification Authority проверяем наличие выданных и отозванных ранее сертификатов.

Далее нам остаётся восстановить информацию о конфигурации ЦС в системном реестре Windows из ранее сохранённого *.reg файла.

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

В нашей резервной копии FQDN имя сервера встречается, как минимум, 2 раза — в параметрах CAServerName и WebClientCAMachine. В случае необходимости, вы можете изменить эти параметры.

Закрываем графическую оснастку Certification Authority, запускаем командную строку с правами администратора и выполняем последовательно команды остановки службы сертификации, восстановления настроек реестра из *.reg файла и повторного запуска службы сертификации.

net stop CertSvc
reg import "C:CABackupPSReg-CA1-WS2012R2.reg"
net start CertSvc

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

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

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

Дополнительные источники информации:

• Anthony Bartolo : Step-By-Step: Migrating The Active Directory Certificate Service From Windows Server 2008 R2 to 2019
• PeteNetLive KB ID 0001473 : Moving Certificate Services To Another Server
• Jack Roper : Migrating the AD Certificate Authority Service server role from 2012 R2 to 2019 — ‘template information could not be loaded’ error
• Microsoft Q&A : Move from DC 2012R2 to 2022 and move CA role

Установка корневого центра сертификации Microsoft CA на MS Windows Server 2008 R2

Назначение корпоративного центра сертификации

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

Однако текущее положение в этой области не позволяет решать вопросы
безопасного интернета без существенных финансовых затрат на
приобретение SSL- сертификатов. При этом
бесплатные сертификаты сервиса
Let’s Encrypt покрывают лишь узкий спектр корпоративных потребностей в
сертификатах. Например, не покрываются сертификаты для шифрования
документов, почты, цифровых подписей, аутентификация клиентов. Для
использования публичных сертификатов, выданных коммерческими CA вам
необходимо иметь публичный домен. Получить сертификат для веб-сервера
на имя domain.local от Let’s Encrypt технически невозможно. Именно
поэтому актуальность частных корпоративных центров сертификации
остаётся на очень высоком уровне.

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

Здесь корневой ЦС
выпускает сертификаты для подчинённых ЦС, а уже
подчинённый ЦС
выдаёт сертификаты конечным потребителям. Это позволяет
изолировать корневой ЦС от сети, что автоматически сводит к нулю шанс
компрометации такого ЦС. Основное время корневой ЦС жизни может и
должен проводить в выключенном состоянии. Включать его нужно только для
обновления собственного сертификата, подчинённого ЦС или для публикации
нового списка отозванных сертификатов (CLR). Другим достоинством
двухуровневой иерархии является улучшенная гибкость в разбиении
подчинённых ЦС на классы, например, для разных групп потребителей или
отдельно для рабочих станций, отдельно для пользователей.

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

Типовая схема двухуровневой схемы центра сертификации (ЦС):

Установка корневого центра сертификации Microsoft CA на MS Windows Server 2008 R2

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

1. Создать файл политик центра сертификации.
2. Установить автономный корневой Центр сертификации (со службой
   сертификации и службой регистрации в центре сертификации через
   Интернет) MS Windows Server 2008 R2. Настроить службу на
   автоматический выпуск сертификатов.
3. Настроить службу на автоматический выпуск сертификатов.
4. Включить аудит работы службы, сделать настройки безопасности.
5. Добавить ссылки на точку распространения отозванных сертификатов и
   корневого сертификата центра сертификации, которые будут добавляться в
   каждый выпущенный сертификат.

Создание файла политик CAPolicy.inf корневого ЦС

Считаем, что для самоподписанного сертификата корневого Центра
сертификации нет необходимости указания точки распределения списка
отозванных сертификатов (расширение CDP). Для этого в файле политик
значение CRL Distribution Point (точка распределения списка отозванных
сертификатов) сделать пустым.

Содержимое файла CAPolicy.inf будет следующим:

[Version] Signature=”$Windows NT$”

[CRLDistributionPoint]

URL=» «

Установка службы сертификации из состава MS Windows

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

1. Открыть окно Панели управления, выполнив команды Пуск, Панель управления.
2. В окне Панели управления открыть пункт Администрирование и выбрать
   Диспетчер сервера.
3. Выбрать пункт Роли. В правой части окна нажать Добавить роли и выделить пункт
   Службы сертификации Active Directory.
   В следующем окне мастера выбрать пункты Центр Сертификации —и Служба регистрации
   в центре сертификации через Интернет.



4. В появившемся окне нажать кнопкуДобавить требуемые службы роли:





5. Далее следует выбрать Автономный ЦС, затем – Корневой ЦС.
6. При создании нового ключа ЦС выбрать опцию Создать новый закрытый ключ.
7. Далее следует выбрать криптопровайдер RSA#Microsoft Software Key
   Storage Provider и установить опцию Разрешить взаимодействие с администратором,
   если центр сертификации обращается к закрытому ключу.



8. Далее следует ввести сведения о ЦС. Имя ЦС (в примере это MS-Root-CA)
   может быть введено как кириллицей, так и латиницей. При этом если имя
   вводится кириллицей, то его длина не должна превышать 50 символов. Если
   Имя вводится латиницей, то его длина не должна превышать 250 символов.
   Имя ЦС может быть любым.
9. Ввести сведения о Вашей организации по следующему
   примеру:

OU= название отдела

O=название организации

L=город местонахождения

C=RU

На сообщение о расширенной кодировке имен выбираем Да.

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

Настройка корневого Центра сертификации

Запускаем центр сертификации: ПускВсе программыАдминистрированиеЦентр сертификации.

Просмотреть настройки Центра сертификации — вызвать контекстное меню и выбрать Свойства.

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

Настроить Модуль политики на выдачу сертификатов в
автоматическом режиме. Установить переключатель в строку Следовать параметрам…

Перейти в закладку Аудит. Включить протоколирование
событий безопасности. Активировать события безопасности, кроме Сохранение и
восстановление архивированных ключей и Запуск и остановка службы сертификатов Active Directory

Перейди в закладку Безопасность. Разрешите Администратору
запрашивать сертификаты:

Настройка публикации списка отозванных сертификатов

Перейти в закладку Расширения. В меню Выберите расширение
выбрать Точка распространения списка отзыва (CDP).
Удалить точки распространения, кроме C:Windows.Добавить путь,
например, https://servername /Public/Certname.crl, где
servername – сервер, на котором будет настроено публичное
хранилище, а Certname – название сертификата.

Включить настройки Включать в CDP-расширение выданных сертификатов и
Включать в расширения IDP выданных CRL. Перезапустить центр сертификации.

В дополнение к CDP, необходимо сконфигурировать дополнение, включающее
информацию о локализации сертификата ЦС AIA. Для этого в поле Выберите расширение
перейти к Authority Information Access (AIA). Удалить доступы к
сведениям о центрах сертификации, кроме C:Windows…. Добавить путь,
например, https://servername/Public/Certname.ce, где servername –
сервер, на котором будет настроено публичное хранилище, а Certname – название сертификата.

Включить настройки Включать в AIA-расширение выданных сертификатов.
Перезапустить Центр сертификации.

Поскольку значения дополнений CDP и AIA изменены, то для учета
изменений необходимо выпустить и опубликовать CRL. Для публикации CRL
необходимо в дереве консоли Центра сертификации нажать правой кнопкой
мыши на узел Отозванные сертификаты. В появившемся меню
выбрать Все задачи — Публикация

Оставить по умолчанию тип публикуемого CRL – Новый базовый CRL.
Нажать кнопку ОК.

Для просмотра и изменения параметров публикации CRL в окне контекстного
меню выберем Свойства.

Посмотреть выпущенные списки отозванных сертификатов можно в закладке
Просмотр списков отзыва сертификатов (CRL).

Списки отозванных сертификатов размещены в папке
C:WindowsSystem32CertsrvCertEnroll,
куда по умолчанию публикуются списки.

Раздел содержит инструкцию по установке и настройке Служб сертификации в операционной системе Windows Server 2012 R2.

Для настройки необходим компьютер с установленной операционной системой Windows 2012 R2 Server Rus и драйверами Рутокен, а также дистрибутив этой ОС.

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

В качестве примера используется учетная запись Administrator.

Этапы установки и  настройки Служб сертификации:

1 этап:  Установка Служб сертификации.

2 этап: Добавление шаблонов сертификатов в Центр Сертификации.

3 этап: Выписка сертификатов пользователю Administrator и обычным пользователям с помощью mmc-консоли.

Установка Служб сертификации

Для установки Служб сертификации:

1. Откройте Диспетчер серверов.
2. Щелкните по названию пункта меню Управление и выберите пункт Добавить роли и компоненты.
   
3. В окне Мастер добавления ролей и компонентов ознакомьтесь с информацией и нажмите Далее.   
   
4. Установите переключатель в положение Установка ролей или компонентов и нажмите Далее.
   
5. Установите переключатель в положение Выберите сервер из пула серверов.
6. В таблице Пул серверов щелкните по имени необходимого сервера.  
7. Нажмите Далее.
   
8. Установите флажок Службы сертификации Active Directory.
   
9. В появившемся окне нажмите Добавить компоненты. В результате флажок отобразится рядом с названием выбранной роли сервера.
   
10. Нажмите Далее.
11. В окне для выбора компонентов нажмите Далее.
    
12. Ознакомьтесь с информацией и нажмите Далее.
    
13. Установите флажок Центр сертификации и нажмите Далее.   
    
14. Чтобы запустить процесс установки нажмите Установить. 
    
15. Дождитесь завершения процесса установки и нажмите Закрыть.  
    
16. В левой части окна Диспетчер серверов щелкните по названию пункта Службы сертификации Active Directory.
17. Щелкните по ссылке Подробнее.
18. В строке с названием необходимой задачи в столбце Действие щелкните по ссылке Настроить службы сертификатов Active Directory.
    
19. Ознакомьтесь с информацией и нажмите Далее.
    
20. Установите флажок Центр сертификации и нажмите Далее.
    
21. Установите переключатель рядом с названием необходимого варианта установки ЦС (в данном примере выбирается ЦС предприятия) и нажмите Далее.
    
22. Установите переключатель рядом с названием типа ЦС (в данном примере выбирается Корневой ЦС, поскольку это будет основной центр сертификации в домене). Нажмите Далее.
    
23. В окне для указания типа закрытого ключа укажите секретный ключ, который будет использоваться для центра сертификации (в данном примере выбирается пункт Создать новый закрытый ключ, поскольку ранее не был создан секретный ключ для центра сертификации). Нажмите Далее.
    
24. В следующем окне для указания параметров шифрования в раскрывающемся списке Выберите поставщика служб шифрования выберите криптопровайдер.
25. В раскрывающемся списке Длина ключа выберите необходимое значение.
26. Щелкните по названию необходимого хеш-алгоритма.
27.  Нажмите Далее. 
    

28. В окне для указания имени ЦС введите значения всех полей и нажмите Далее.
    

    Введенные здесь данные носят информативный характер. Рекомендуется их внести. Аббревиатуры несут следующий смысл: «O» — Organization, «OU» — Organization Unit, «L» — City (Location), «S» — State or province, «C» — Country/region, «E» — E-mail.  

29. Введите период действия сертификата для создаваемого ЦС. 
     

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

30. В поле Расположение базы данных сертификатов введите путь до базы данных и нажмите Далее.  
    
31. Ознакомьтесь с информацией и нажмите Настроить. 
     
32. Дождитесь завершения процесса установки и нажмите Закрыть.
     

Добавление шаблонов сертификатов в Центр Сертификации

Для добавления шаблонов сертификатов:

1. Откройте Панель управления.
2. Два раза щелкните по названию пункта Администрирование.
3. Два раза щелкните по названию оснастки Центр сертификации. 
   
4. Правой кнопкой мыши щелкните по названию папки Шаблоны сертификатов и выберите пункт Управление. 
   
5. Правой кнопкой мыши щелкните по названию шаблона Пользователь со смарт-картой и выберите пункт Скопировать шаблон. Откроется окно Свойства нового шаблона.
   

   

6. Выберите следующие настройки:
    

   Значение параметра Минимальный размер ключа должно быть не менее 1024.

   

7. Нажмите Применить.
8. Нажмите OK.
9. Перейдите в окно Центр сертификации.
10. Правой кнопкой щелкните по названию папки Шаблон сертификатов.
11. Выберите пункт Создать и подпункт Выдаваемый шаблон сертификата.
     
12. В окне Включение шаблонов сертификатов щелкните по названию шаблона Агент регистрации.
13. Удерживайте клавишу Ctrl.  
    
14. Щелкните по названию шаблона Пользователь с RuToken.
15. Нажмите ОК.
16. Закройте окно Центр сертификации. 

Выписка сертификатов пользователю Administrator и обычным пользователям с помощью mmc-консоли

Для выписки сертификатов пользователю Administrator и обычным пользователям с помощью mmc-консоли:

1. Нажмите комбинацию клавиш Windows + X и выберите пункт меню Выполнить.
2. Введите команду «mmc» и нажмите OK. 
   
3. В окне Консоль1 выберите пункт меню Файл и подпункт Добавить или удалить оснастку…
   
4. В левой части окна Добавление и удаление оснасток щелкните по названию оснастки Сертификаты.
5. Нажмите Добавить. 
   
6. В открывшемся окне установите переключатель моей учетной записи пользователя и нажмите Готово.
   
7. В окне Добавление и удаление оснасток нажмите OK.
   
8. В левой части окна Консоль 1 щелкните по названию папки Личные.
9. Щелкните по названию папки Сертификаты.
10. В правой части окна щелкните правой кнопкой мыши в свободном месте окна.
11. Выберите пункт Все задачи и подпункт Запросить новый сертификат…
     
12.  В окне Регистрация сертификатов ознакомьтесь с информацией и нажмите Далее.
     
13. Нажмите Далее. 
    
14. Установите флажок Администратор и нажмите Заявка.
    
15. Нажмите Готово.
    
16. В левой части окна Консоль 1 щелкните по названию папки Личное.
17. Щелкните по названию папки Сертификаты.
18. В правой части окна щелкните правой кнопкой мыши в свободном месте окна.
19. Выберите пункт Все задачи и подпункт Запросить новый сертификат…
     
20. В окне Регистрация сертификатов ознакомьтесь с информацией. Нажмите Далее. 
     
21. Нажмите Далее. 
    
22. Установите флажок Агент регистрации и нажмите Заявка.
     
23. Нажмите Готово.
     
24. В левой части окна Консоль 1 щелкните по названию папки Личное.
25. Правой кнопкой мыши щелкните по названию папки Сертификаты и выберите пункт Все задачи.
26. Выберите подпункт Дополнительные операции.
27. Выберите подпункт Зарегистрироваться от имени…
    
28. Ознакомьтесь с информацией и нажмите Далее.
     
29. Нажмите Далее. 
     
30. Нажмите Обзор.
    
31. Щелкните по имени сертификата типа Агент регистрации (чтобы определить тип сертификата откройте свойства сертификата).
32. Нажмите OK.
     
33. Нажмите Далее.
     
34. Установите переключатель в положение Пользователь с RuToken и нажмите Далее. 
    
35. В окне Регистрация сертификатов нажмите Обзор.
    
36. В поле Введите имена выбираемых объектов введите имя пользователя, которому будет выписан сертификат типа Пользователь RuToken.
37. Нажмите Проверить имена.
    
38. Нажмите OK.
    
39. Поле Имя пользователя или псевдоним заполнится автоматически.
40. Нажмите Заявка.
    
41. Введите PIN-код Пользователя и нажмите OK. 
    
42. Нажмите Закрыть. 
    
43. В результате сертификат типа Пользователь с RuToken выписан и сохранен на токене.
44. Чтобы просмотреть свойства этого сертификата нажмите Открыть сертификат. 
    
45. Чтобы закрыть окно сертификата нажмите OK.
46. Аналогичным способом выпишите сертификаты для всех пользователей, которым они необходимы. Пользователю Администратор так же необходимо выписать сертификат типа Пользователь с RuToken.
47. В окне Консоль1 выберите пункт: Файл — Добавить или удалить оснастку.
    
    
48. В окне для добавления и удаления оснастки выберите в списке доступных оснасток пункт Сертификаты.
    
    
49. Установите переключатель учетные записи компьютера.
    
50. Выберите пункт: Корень консоли — Сертификаты — Личные — Сертификаты — Все задачи — Запросить новый сертификат.
    
    
51. Установите галочку Проверка подлинности контроллера домена и нажмите Заявка.
    
    

52. Закройте окно Консоль1. Для сохранения консоли нажмите Да.
    

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

53. Если консоль не надо сохранять, то нажмите Нет. При этом не сохранятся только настройки консоли, выписанные сертификаты будут сохранены в системе. 
54. Введите имя файла для хранения настроек консоли и нажмите Сохранить.
    

На этом настройка Центра Сертификации и выдача сертификатов пользователям завершены.