Windows server сервер сертификации — Ваш верный помощник с OS Windows

Всем привет, с вами Искандер Рустамов, младший системный администратор 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)

Рисунок 1. Установка дополнительных компонентов «КриптоПро CSP»

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

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

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

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

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

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

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

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

Начинаем:

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

Рисунок 2. Уведомления при установки роли.

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

Рисунок 3. Интерфейс «Диспетчера устройств» (Server Manager)

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);

Рисунок 4. «Выбор сервера (Server selection)»

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)

Рисунок 5. Уведомление о необходимости настройки центра сертификации

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)

Рисунок 6. Выбор ключевого носителя – КриптоПРО CSP

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)»;

Рисунок 7. Выбор криптопровайдера

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. Далее появится окно результатов об успешной установке компонентов (рис.

Рис.8. Результаты установки

Настройка веб-сервера 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-сертификат.

Рисунок 9. Диспетчер служб IIS (IIS Manager)

Также сертификат вы можете выпустить следующим образом:
На этой же панели создайте запрос (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):

Рисунок 10. Настройка центра сертификации. Оснастка управления центром сертификации certsrv.

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)»

Рисунок 11. Настройка точек распространения AIA и CRL

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

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

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

Рисунок 12. Дополнительные настройки ЦС для автоматического выпуска сертификатов

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

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

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

Рисунок 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'

Рисунок 14. Настройка параметров публикации CRL.

Настройка 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 ca\validityperiodunits

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

Рисунок 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 "Цифра запроса"

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

Рисунок 16. Выпуск сертификата для сетевого автоответчика

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.

Рисунок 16.1. Настройка сертификата для работы сетевого ответчика

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 (для разностного).

Рисунок 17. Управление сетевым ответчиком. (online responder management)

Рисунок 18. Прикрепляем конфигурации корневой сертификат ЦА

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

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

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

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

Рисунок 19. Итоговый результат о работе сетевого ответчика

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

Рисунок 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;

Картинка с сайта: vmblog.ru
В списке компонентов роли AD CS выберите Certification Authority;

Картинка с сайта: vmblog.ru
После окончания установки, нужно выполнить первичную настройку роли ADCS. Для этого в Server Manager нажмите на флажок и щелкните по пункту Configure Active Directory Certificate Services on the destination server;

Картинка с сайта: vmblog.ru
Выберите сервисы для настройки;

Картинка с сайта: vmblog.ru
Так как сервер rootCA не добавлен в домен AD, выберите здесь Standalone CA -> Root CA;
Root CA» srcset=»https://vmblog.ru/wp-content/uploads/2023/11/ustanovit-standalone-ca-greater-root-ca.png 441w, https://vmblog.ru/wp-content/uploads/2023/11/ustanovit-standalone-ca-greater-root-ca-300×199.png 300w, https://vmblog.ru/wp-content/uploads/2023/11/ustanovit-standalone-ca-greater-root-ca-263×175.png 263w»>

Картинка с сайта: vmblog.ru
Выберите Create a new private key;

Картинка с сайта: vmblog.ru

Параметры ключа оставьте по умолчанию:

Cryptographic provider: RSA
Key length: 2048
Hash algorithm: SHA256

Картинка с сайта: vmblog.ru
Имя CN можно оставить без изменений;
На странице Validity period укажите срок действия сертификата CA (укажите 15 лет здесь);

Картинка с сайта: vmblog.ru
Оставьте пути к базе данных CA и логам по умолчанию: c:\windows\system32\certlog

Картинка с сайта: vmblog.ru
Если все настроено верно, появится надпись: Configuration succeeded.

Картинка с сайта: vmblog.ru

Совет. Вы можете установить роль 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…”;

Картинка с сайта: vmblog.ru
Укажите имя политики и перейдите в режим редактирования;
Перейдите в 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

Картинка с сайта: vmblog.ru

Обновите политики на клиентах и проверьте, что ваш корневой сертификат появился в Trusted Root Certificates.

Источник

В настоящей статье мы рассмотрим, что такое Active Directory Certificate Services и выполним базовое развертывание и настройку.

Active Directory Certificate Services (ADCS) – это серверная роль Windows Server, которая позволяет нам развернуть инфраструктуру PKI внутри корпоративного домена. В зависимости от размеров вашей сети, требований бизнеса, требований службы безопасности вашей организации может быть организована такая архитектура открытых ключей, которая будет соответствовать всем предъявляемым требованиям.

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

Планируемая инфраструктура

Перед началом работ необходимо составить план и нарисовать схему, которую мы будем реализовывать. Как я уже писал выше – у нас будет двухуровневая инфраструктура PKI. Архитектура решения представлена на рисунке ниже:

В данной схеме представлены следующие объекты:

Объект	Описание
Root CA	Корневой центр сертификации. На данном сервере будет сформирован корневой сертификат, после чего данный сервер будет находиться в выключенном состоянии для уменьшения возможности компрометации ключа.
Subordinate CA	Издающий центр сертификации. Данный сервер будет находиться в домене и должен быть в постоянно включенном состоянии. Данный сервер будет выдавать сертификаты для серверов и клиентов.
Infrastructure Servers	Инфраструктурные серверы или сервисы, которым необходимы сертификаты для полноценной работы
Application Servers	Различные серверы приложений
Clients	Клиентские рабочие станции

Развертывание инфраструктуры

Развертывание корневого центра сертификации

1. Заходим на сервер корневого центра сертификации;

2. Идем в Server Manager – Manage – Add Roles and Features:

3. Откроется Add Roles and Features Wizard:

На странице Before you begin нажимаем Next;

4. В окне Installation Type оставляем все по умолчанию и нажимаем Next:

5. На странице Select destination server выбираем наш сервер:

И нажимаем Next;

6. На странице Select server roles выбираем Active Directory Certificate Services:

Нам сразу будет предложено установить Remote Server Administration Tools. Нажимаем Add Features и затем нажимаем Next;

7. На странице Select features нажимаем Next;

8. На странице Active Directory Certificate Services нажимаем Next;

9. На странице Select role services убеждаемся, что у нас выбран пункт Certification Authority (он, как правило, выбран по умолчанию):

И нажимаем Next;

10. На странице Confirm installation selections нажимаем Install:

11. Начнется процесс установки:

12. После окончания установки мы увидим такое окно:

Для продолжения настройки выбираем Configure Active Directory Certificate Services on the destination server;

13. Откроется окно AD CS Configuration:

На странице Credentials необходимо указать учетные данные. Поскольку у нас сервер будет недоменный и настройка в режиме Standalone, то оставляем нашу административную учетную запись по умолчанию и нажимаем Next;

14. На странице Role Services выбираем Certification Authority и нажимаем Next:

15. На странице Setup Type выбираем Standalone CA и нажимаем Next:

16. На странице CA Type выбираем Root CA и нажимаем Next:

17. На странице Private Key выбираем Create a new private key:

И нажимаем Next;

18. На странице Cryptography for CA оставляем все по умолчанию и нажимаем Next:

19. На странице CA Name:

Заполняем поле Common name for this CA. Остальные поля в рамках нашей сегодняшней инфраструктуры мы не трогаем. Нажимаем Next;

20. На странице Validity Period выставляем 15 лет и нажимаем Next:

21. На следующей странице CA Database можно настроить пути для баз данных:

Оставляем все по умолчанию и нажимаем Next;

22. На странице Confirmation проверяем наши настройки и нажимаем Configure:

23. Начнется процесс установки и если все хорошо, то мы увидим такую страницу:

24. Идем в Server Manager – Tools – Certification Authority:

25. И попадаем в консоль CA:

Далее, идем по стандартрому пути C:\Windows\System32\CertSrv\CertEnroll и копируем оттуда сертификат и список отзыва сертификатов. Они нам понадобятся на этапе настройки выдающего центра сертификации.

Настройка выдающего центра сертификации

Для начала нам необходимо установить службу ADCS на нашем сервере, который будет выполнять роль выдающего центра сертификации. Для развертывания данной роли повторяем шаги 2-12 из раздела «Развертывание корневого центра сертификации«. После того, как мы завершили установку службы сертификатов, перейдем к ее настройке.

1. Откроется окно мастера AD CS Configuration:

На странице Credentials необходимо выбрать доменную учетную запись с правами Domain Admin и Enterprise Admin и нажимаем Next;

2. На странице Role Services необходимо выбрать роль Certification Authority:

И нажимаем Next;

3. На странице Setup Type выбираем Enterprise CA:

И нажимаем Next;

4. На странице CA Type выбираем Subordinate CA:

И нажимаем Next;

5. На странице Private Key выбираем Create a new private key:

И нажимаем Next;

6. На странице Cryptography for CA оставляем все по умолчанию и нажимаем Next;

7. На странице CA Name указываем имя в поле Common name for this CA:

И нажимаем Next;

8. На странице Certificate Request необходимо выбрать вариант запроса к корневому центру сертификации:

Выбираем (если не выбран) Save a certificate request to file on the target machine и нажимаем Next;

9. На странице CA Database оставляем все по умолчанию и нажимаем Next;

10. На странице Confirmation проверяем наши настройки и если все в порядке, то нажимаем Configure:

11. Начнется установка, и после завершения на странице Result можно посмотреть результаты установки:

Как видим, система сообщает, что установка полностью не завершена, поскольку не установлен сертификат. Этим сейчас и займемся.

Получение сертификата с корневого центра сертификации

1. Копируем наш созданный *.req – запрос на сервер RootCA в корень диска C;

2. На сервере RootCA запускаем CMD имени администратора и выполняем следующую команду:

certreq -submit "C:\subordCA.domain.com_domain-SUBORDCA-CA-1.req"

3. Во время запуска команды появится окно Certification Authority List:

Выбираем наш CA и нажимаем ОК;

4. Если запрос выполнен успешно, то мы увидим сообщение примерно такого содержания:

Нам сообщают, что наш запрос на сертификат ждет выдачи;

5. Идем по пути Server Manager – Tools – Certification Authority:

6. Заходим в Pending Requests:

И видим наш запрос с присвоенным Request ID 2;

7. Вызываем контекстное меню:

Выбираем All Tasks – Issue;

8. Переходим в Issued Certificates и видим наш сертификат:

9. Возвращаемся в командную строку и вводим следующую команду:

certreq -retrieve 2 C:\SubCA.crt

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

10. В форме Certification Authority List выбираем наш CA и нажимаем ОК;

11. Теперь у нас готов сертификат для нашего промежуточного сервера Subordinate CA.

Теперь, мы должны скопировать полученный нами сертификат, а также корневой сертификат и список отзыва (которые мы получили раньше) на наш промежуточный сервер сертификации в каталог C:\Install.

Установка корневого и промежуточного сертификатов

1. Открываем PowerShell с правами администратора и выполняем следующие команды:

certutil -dspublish -f "C:\install\RootCA_CompanyRootAuthority.crt"
certutil -addstore -f root "C:\install\RootCA_CompanyRootAuthority.crt"
certutil -addstore -f root "C:\install\CompanyRootAuthority.crl"

Данными командами мы выполняем публикацию и добавление корневого сертификата, полученного от сервера RootCA и список отзыва сертификатов. Если все команды отработали успешно, то можно устанавливать полученный сертификат SubCA.crt;

2. Открываем CMD от имени администратора и вводим следующую строку:

certutil -installcert C:\install\SubCA.crt

Эта команда установит наш сертификат на сервер Subordinate CA;

3. Если команда отработала без ошибок, то необходимо выполнить запуск службы CertSrv и наш сервер выдачи сертификатов готов к работе:

Итог

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

Источник

Установка и настройка Active Directory Certificate Services

В этой статье я подробно расскажу о процессе установки и настройки Active Directory Certificate Services.

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

В примере я разбираю Active Directory Certificate Services на операционной системе Windows Server 2012.

Первым делом нам нужно установить службу сертификации Active Directory.

Для этого нужно запустить диспетчер сервера.

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

Выбираем пункт установка ролей или компонентов, а затем выбираем наш сервер.

В следующем окне выбираем пункт службы сертификатов Active Directory.

В окне выбора компонентов жмем далее.

В окне служба ролей выбираем пункт центр сертификации.

Запускаем процесс установки.

После этого по аналогии устанавливаем веб-службу регистрации сертификатов.

Установка завершена. Перейдем к настройке.

Настройка службы сертификатов Active Directory

Заходим в настройки.

Выбираем службу центр сертификации.

Вариант установки – центр сертификации предприятия.

Тип центра сертификации – корневой. Это необходимо для того, что бы в дальнейшем мы могли самостоятельно выдавать и подписывать сертификаты.

В следующем окне нужно выбрать пункт создать новый закрытый ключ.

Затем необходимо указать параметры шифрования. Вы можете указать свои параметры, или параметры как у меня на рисунке ниже.

В следующем окне указывается имя центра шифрования.

Затем указывается срок действия центра сертификации. По умолчанию он равен 5 годам. Так и оставим.

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

Подтверждаем настройку.

Перейдем к настройке web-службы регистрации сертификатов.

Настройка web-службы регистрации сертификатов

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

Тип проверки подлинности – имя пользователя и пароль.

Учетная запись службы CES – использовать встроенное удостоверение пула приложений.

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

Настройка выполнена.

Картинка с сайта: abuzov.com

Выберите тип проверки подлинности – имя и пароль пользователя.

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

Перезагрузите сервер.

Установка и настройка удостоверяющего центра

Запустите консоль управления Microsoft (пуск, выполнить, mmc).

Далее нажмите файл, а затем добавить или удалить оснастку.

В левой части нужно выбрать пункт «Сертификаты» и нажать кнопку добавить.

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

В следующем окне ничего не меняем и нажимаем кнопку готово. Оснастка добавлена.

В левой части окна можно увидеть папки, в которых хранятся сертификаты (11 штук). Они сортированы по типам сертификатов. Если нажать на папку «Личное» то можно посмотреть сертификаты в этой папке.

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

Появится окно перед началом работы. Жмем далее.

Видим окно запрос сертификатов и нажимаем «заявка».

Запускается процесс установки сертификата. После успешной установки появиться следующая надпись «Состояние: Успешно».

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

В левой части окна нажать сайты, default web site, изменить привязки.

В появившемся окне нажмите добавить и введите данные как на изображении ниже.

Сохраните изменения и закройте окно.

Для проверки работоспособности Центра сертификации запустите браузер Internet Explorer и в строке навигации наберите адрес «https://192.168.0.1/certsrv/» (ip-адрес может отличаться от того, который указали вы).

Управление шаблонами сертификата

Работа с шаблонами сертификата требует установки оснастки «Шаблоны сертификатов». Откроем нашу консоль, которую мы создавали ранее и добавим оснастку «Шаблоны сертификатов».

Откроем шаблоны в главном окне консоли. Создадим новый шаблон.

Сначала нужно выбрать любой шаблон сертификата и нажать скопировать его.

Настроим шаблон. Выберите совместимость шаблона сертификата.

Задайте общие свойства шаблона.

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

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

За это два параметра отвечают для поля «период действия» и «период обновления».

Параметр «опубликовать сертификат в Active Directory» определяет, будут ли сведения о шаблоне сертификата доступными по всему предприятию.

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

Обработка запроса. Цель имеет 4 возможных параметра:

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

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

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

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

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

Вкладка шифрование. Определяется максимальный размер ключа. Я оставлю его без изменений.

Безопасность можно настроить по вашему усмотрению.

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

На этом статья подходит к концу. Мы установили и настроили Active Directory Certificate Services.

Источник

Install Certificate Services on Windows Server 2022

A Certificate Authority is an entity that stores, signs and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures made about the private key that corresponds to the certified public key.

Microsoft’s Certification Authority is based on Public Key Infrastructure. The Active Directory Certificate Services role can be deployed on most Windows Server operating systems and provides the ability to act as an Enterprise or Standalone Root CA.

Using a Windows Root CA server is very useful for many applications, for example – if deploying 802.1x with certificate-based authentication or EAP-TLS for Wireless 802.1x, a Windows Server provides the ability to enrol and automatically distribute certificates to endpoints with ease through Microsoft Group Policy.

A CA Server can also be used to sign certificates for Servers, Network and Security Devices within an internal organisation. Certificate based authentication is considered one of the most secure methods as its uses public key and private key to encrypt and decrypt data.

In this basic step-by-step guide, we will install the Active Directory Certificate Services role and configure it.

A fresh new virtual instance of Windows Server 2022 has been installed, this server has been renamed, basic networking has been configured and it has been joined to the Active Directory Domain.

Let’s get started!

Install the Certification Authority Server Role

1. Login to Windows Server 2022 and launch “Server Manager”

2. Click the “Manage” button select “Add roles and features”

3. At the Wizard click “Next”

4. Select “Role-Based or Feature-based installation” and click “Next”

5. Click “Select a server from a server pool” and highlight the current server, click “Next”

6. Tick the “Active Directory Certificate Services” box, a new Window will pop up click “Add Features”

7. Click “Next”

8. At the features window, click “Next” we are not installing any additional features

9. Read of the role description and, note the tasks that cannot be performed once the CA role is installed. click “Next”

10. From the role services list select “Certification Authority” and “Certification authority Web Enrollment”

Click “Add Features” at the popup for IIS installation

11. Click “Next”

12. Click “Next”

13. Click “Next”

14. Select the “Restart the destination server automatically if required” tick box. This will allow the server to restart automatically if a reboot is required at the end of the install. Finally click “Install”

15. Once the role is installed, click “Close”

Configure the Role

1. From Server Manager click on the yellow warning message, select “Configure Active Directory Certificate Services on this Server”

2. At the configuration wizard click “change”

3. Provide the Domain Admin user account credentials and click “OK”

4. Note the change in the “Credentials” window, click “Next”

5. Tick both role services and click “Next”

6. Select “Enterprise CA” and click “Next”

7. Select “Root CA” and click “Next”

8. Select “Create a new private key” and click “Next”

9. Leave the default values for the private key information and click “Next”

10. Specify the common name for the CA or leave as default. Click “Next”

11. Specify the CA Certificate default validity period, this is set to 5 years by default, this can be changed if required, Click “Next”

12. leave the default location of storing the database files and click “Next”

13. Review the configuration and click “Configure”

14. Once configuration has successfully completed, click “Close”

Configure IIS

By default, IIS does not have HTTPS enabled for the web enrollment service, we need to allow HTTPS connections and define a certificate for the service to use. HTTP connections will work, however in the event the CA server is being accessed from another source to request a certificate, the credentials will be sent over in clear text. It’s important we modify this to use SSL.

1. Click “Start” and type “IIS Manager”

2. Expand “Server Name” – “Sites”, right click “Default Web Site” and select “Edit Bindings”

3. Click “Add”

4. Select “https” then from the “SSL Certificate” drop down menu, Select the Server certificate that should have been generated automatically by the CA, in this case it’s the “LNS-LNS-CA-01-CA”.

If for any reason this certificate is not yet present, one can be generated by selecting “Create a Self-Signed” Certificate” from the right-hand pane within IIS.

Click “View” to check the contents of the certificate, then click “OK, and “OK” to save the changes and return to the IIS window.

5. From the right-hand pane within IIS, select “Browse*:443 (https)”

6. The browser will launch with “https://localhost/certsrv” in the address field. Click “Continue”

From the web interface, we can start requesting certificates from the CA for our organisation. To access this portal from other devices, you can navigate to “https://IP Address or DNS name/certsrv”

Источник