Всем привет, с вами Искандер Рустамов, младший системный администратор 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)
Криптопровайдер уровня ядра ОС необходим для работы криптопровайдера
в службах и ядре 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. Появится окно выбора носителя для создания контейнера нашего ЦС.
Где хранятся сами контейнеры ключей:
1. Реестр: (в качестве хранилища ключей используется реестр Windows), путь хранения контейнеров ключей следующий:
Ключи компьютера: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CryptoPro\Settings\Keys
Ключи пользователя ОС: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CryptoPro\Settings\Users\SID-пользователя\Keys
В некоторых случаях (было замечено в виртуальных машинах) сертификат попадает сюда: HKEY_USERS\S-1-5-21-{SID}_Classes\VirtualStore\MACHINE\SOFTWARE\[Wow6432Node]\
CryptoPro\Settings\USERS\{SID-пользователя}\Keys\ //
2. Директория: (в качестве хранилища ключей используется директория на жёстком диске), путь хранения контейнеров ключей следующий: C:\Users\All Users\Crypto Pro\Crypto
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 = Empty1.2. Откройте командную строку cmd. Перейдите в директорию с текстовым файлом или в будущем просто укажите полный путь при формировании запроса.
1.3. Узнаем, на какой срок сейчас выпускаются сертификаты. Для этого воспользуемся командой - certutil –getreg ca\validityperiodunits
Результат — на рис. 15.
1.4. Изменим длительность выпуска сертификата:
#Изменение выпуска сертификатов с текущего состояния на длительность в 5 лет
certutil -setreg ca\ValidityPeriodUnits 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-канал, чтобы не пропустить очередную статью. Пишем только по делу.
Служба сертификации Active Directory (AD CS) позволяет развернуть вам собственную инфраструктуру PKI в доменной сети, и используется для выдачи и управления сертификатами. В этой статье мы рассмотрим сценарий развертывания центра сертификации: установку корпоративной службы AD CS на Windows Server, настройку групповой политики выдачи сертификатов в домене.
В продуктивной среде не рекомендуется развёртывать службы AD CS на контроллере домене Active Directory. В продуктивной среде нужно реализовать двухуровневую архитектуру PKI:
- Отдельный корневой сервер сертификации (Root CA) – это сервер выдает сертификат для подписи выдающего сервера сертификации. После генерации доверенного корневого сертификата и CRL, этот сервер рекомендуется выключить (это позволит снизить риски компрометации ключа). В нашем примере этот сервер называется RootCA;
- Выдающий сервер сертификации (Subordinate CA) – это основной сервер, который будет выдавать сертификаты клиентам в организации. Также он хранит список отозванных сертификатов и используется для проверки отозванных сертификатов. Имя сервера subordCA
Служба сертификации Active Directory Certificate Services это одна из стандартных ролей Windows Server 2022/2019/2016.
Сначала нужно настроить корневой CA (сервер RootCA). Это Windows Server, который не нужно добавлять в домен AD.
Запустите Server Manager и выберите Add roles and features;
- Выберите текущий сервер, в списке ролей отметьте Active Directory Certification Authority и нажмите Next;
- В списке компонентов роли AD CS выберите Certification Authority;
- После окончания установки, нужно выполнить первичную настройку роли ADCS. Для этого в Server Manager нажмите на флажок и щелкните по пункту Configure Active Directory Certificate Services on the destination server;
- Выберите сервисы для настройки;
- Так как сервер rootCA не добавлен в домен AD, выберите здесь Standalone CA -> Root CA;
Параметры ключа оставьте по умолчанию:
Cryptographic provider: RSA
Key length: 2048
Hash algorithm: SHA256
Совет. Вы можете установить роль ADCS в Windows Server с помощью PowerShell:
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
После установки роли AD CS выполните команду:
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA
Для управления ADCS используется специальная оснастка Certification Authority (certsrv.msc). Запустите ее.
Затем откройте каталог C:\Windows\System32\CertSrv\CertEnroll и скопируйте оттуда сертификат и список отзыва сертификатов. Эти файлы понадобятся в дальнейшем при настройке выдающего центра сертификации.
Теперь переходим к настройке второго сервера Subordinate CA (subordCA).
- Установите на нем роль AD CS, со следующими компонентами:
- Certification Authority
- Certification Authority Web Enrollment
- Certification Authority Web Service
- Выберите тип CA — Subordinate CA;
- На странице Private Key выберите Create a new private key;
- Настройки криптографии оставьте по умолчанию, задайте Common Name
- На странице Certificate request выберите Save a certificate request to file on the target machine;
- Нажмите Configure чтобы начать установку.
Теперь нужно получить сертификат от вашего rootCA на основе вашего запроса:
- Скопируйте файл *.reg в корень диска C:\ на rootCA;
- Выполните команду:
certreq -submit "C:\subordCA.tect.loc_ SUBORDCA-1.req" - Появится окно Certification Authority List, в котором нужно выбрать ваш rootCA и нажмите OK;
- Теперь откройте консоль Certification Authority на Root CA и перейдите в раздел Pending Requests. Ваш запрос должен появится в этой консоли. Запомните номер запроса, например Request ID 2. Щелкните по нему правой кнопкой и выберите All Tasks -> Issue;
- Экспортируйте подписанный сертификат в файл с помощью команды:
certreq -retrieve 2 C:\SubordCA.crt
Скопируйте файл SubordCA.crt на промежуточный сервер сертификации. Установите корневые сертификаты и список отзыва, которые вы скопировали ранее:
certutil -dspublish -f "C:\PS\RootCA.crt"
certutil -addstore -f root "C:\PS\RootCA.crt"
certutil -addstore -f root "C:\PS\RootCA.crl"
Теперь установите сертификат, который вы подписали:
certutil -installcert C:\PS\SubordCA.crt
Запустите службу CertSrv. Ваш промежуточный сервер сертификации готов к выдаче сертификатов. Хост RootCA можно отключить.
Теперь можно настроить в домене групповую политику для автоматической выдачи сертификатов (autoenrollment) для клиентов домена.
- Откройте консоль Group Policy Management, щелкните по корню домена и выберите “ Create a GPO in this domain, and Link it here…”;
- Укажите имя политики и перейдите в режим редактирования;
- Перейдите в Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies
- Выберите шаблон «Certificate Services Client — Auto-Enrollment»
- Включите политику и настройте ее следующим образом
Configuration mode: Enabled
Renew expired certificates, update pending certificates and remove revoked certificate
Update certificates that use certificate templates
Обновите политики на клиентах и проверьте, что ваш корневой сертификат появился в Trusted Root Certificates.
