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

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

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

Для настройки необходим компьютер с установленной операционной системой Windows 2019 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. Нажмите ОК.
9. Перейдите в окно Центр сертификации.
10. Правой кнопкой мыши щелкните по названию папки Шаблоны сертификатов.
11. Выберите пункт Создать и подпункт Выдаваемый шаблон сертификатов.
12. В окне Включение шаблонов сертификатов щелкните по названию шаблона Агент регистрации.
13. Удерживайте клавишу Ctrl.
    
    
14. Щелкните по названию шаблона Пользователь с RuToken.
15. Нажмите ОК.
16. Закройте окно Центр сертификации.
    

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

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

1. Нажмите комбинацию клавиш Windows + X и выберите пункт меню Выполнить.
2. Введите команду «mmc» и нажмите ОК.
   
   
3. В окне Консоль 1 выберите пункт меню Файл и подпункт Добавить или удалить оснастку…
   
   
4. В левой части окна Добавление и удаление оснастки щелкните по названию Сертификаты.
5. Нажмите Добавить.
   
   
6. В открывшемся окне установите переключатель моей учетной записи пользователя и нажмите Готово.
   
   
7. В окне Добавление и удаление оснасток нажмите ОК.
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. Нажмите ОК.
    
    
33. Нажмите Далее.
    
    
34. Установите переключатель в положение Пользователь с RuToken и нажмите Далее.
    
    
35. В окне Регистрация сертификатов нажмите Обзор.
    
    
36. В поле Введите имена выбираемых объектов введите имя пользователя, которому будет выписан сертификат типа Пользователь с RuToken.
37. Нажмите Проверить имена.
    
    
38. Нажмите ОК.
    
    
39. Поле Имя пользователя или псевдоним заполнится автоматически.
40. Нажмите Заявка.
    
    
41. Введите PIN-код Пользователя и нажмите ОК.
    
    
42. Нажмите Закрыть.
    
    
43. В результате сертификат типа Пользователь с RuToken выписан и сохранен на токене.
44. Чтобы просмотреть свойства этого сертификата нажмите Просмотреть сертификат.
    
45. Чтобы закрыть окно сертификата нажмите ОК.
46. Аналогичным способом выпишите сертификаты для всех пользователей, которым они необходимы. Пользователю Администратор так же необходимо выписать сертификат типа Пользователь с RuToken.
47. В окне Консоль1 выберите пункт: Файл — Добавить или удалить оснастку.
    
    
48.  В окне для добавления и удаления оснастки выберите в списке доступных оснасток пункт Сертификаты.
    
49. Установите переключатель учетные записи компьютера.
    
50. Выберите пункт: Корень консоли — Сертификаты — Личные — Сертификаты — Все задачи — Запросить новый сертификат.
    
    
51. Установите галочку Проверка подлинности контроллера домена и нажмите Заявка.
    

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

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

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

Note: This guide is archived and is no longer updated on this website. For any future updates to this guide, please refer to the version that can be found on docs.mjcb.io.

Goals of this Guide

The goal of this guide is to deploy an internal Certificate Authority and a Public Key Infrastructure (PKI) using Active Directory Certificate Services in Windows Server 2019. This provides a lot of benefits to an organization, including features like:

• Utilizing SSL on internal Servers and on internal Websites.
• Replacing self-signed Certificates on internal Network Devices.
• Increased security for Remote Desktop Services on internal Servers.
• Utilize internal Certificates for Applications and Services.
• Issue internal Certificates for VPN Services.
• Issue internal Certificates for Wireless Users and Access Points.
• Allow for better security with Active Directory with LDAPS.
• Use your own internal Certificate for SSL Decryption on Firewalls and Proxy Devices.

The procedure for creating a Certificate Authority has not changed considerably since Windows Server 2012 R2. Recent enhancements and changes with some vendors (Apple and Mozilla) do require a few minor changes to allow for security changes with those vendors.

I apologize for the length of this document but creating a Certificate Authority is a very complicated process. I tried to document every single step that I could, as missing even the smallest detail can cause a lot of issues that are very difficult to correct.

Guide

Since this is such a complicated subject there are multiple parts to this guide. Here are the links to each part of the guide:

• Part 1 — Offline Root CA Setup
• Part 2 — Subordinate CA Setup
• Part 3 — Deploy Root and Subordinate Certificate
• Part 4 — Certificate Revocation Policies
• Part 5 — Configure Private Key Archive and Recovery
• Part 6 — Certificate Template Deployment
• Part 7 — Certificate Auto-Enrollment
• Part 8 — Final Steps

Environment Assumptions

All Servers in this guide are using Windows Server 2019 Standard (Desktop Experience), but this should work correctly using Windows Server 2016. In this guide, the Active Directory Domain and Forest Functional Levels are set to Windows Server 2016 levels, but this should work for Windows Server 2012 R2 functional levels.

This guide should work perfectly fine using Hyper-V, VirtualBox or VMware. This guide does not assume any Virtualization platform so there should not be any issues using any Virtualization platform.

For this guide I am using VMware Workstation 15 Pro (15.5.1 build-15018445) on Windows 10 Pro 1909 (Build 18363.657). I am using a Lenovo P51 Mobile Workstation (Intel Core i7-7820HQ @ 2.90GHz and 64 GB RAM).

Environment Design and Overview

This guide uses a simplified and very basic Server Infrastructure and is the bare minimum that is required for Active Directory Certificate Services to operate correctly. It is technically possible to run Active Directory Certificate Services on the same Server as a Domain Controller, but this is very bad practice and can have some unintended consequences if there is ever an issue with it. It is also incredibly insecure to have your Root Certificate Server available at all times.

The example that is going to be used in this guide is the TFS Labs Domain (corp.tfslabs.com). It is very basic in design, and there is a total of 3 Servers, 1 Workstation and 1 iOS Device:

The Virtual Machines that are being used in this guide are using the following specifications:

The iOS device used in this environment is an iPad Air 3 and is running the latest version of iPad OS (13.3.1 as of the time of this writing). It is on wireless on the same network and has an IP address of 192.168.0.213/24.

Here is breakdown of the Servers and Workstations in this environment:

• TFS-DC01 the Domain Controller for the TFS Labs Domain. It is also needed to allow for Certificate distribution and for Group Policy updates to the TFS Labs Domain. It is also the LDAP CDP and AIA Publishing Location. This guide assumes that you already know how to setup a basic Active Directory Domain Controller and Domain and have done this already prior to starting this guide.
• TFS-ROOT-CA is the Offline Root Certificate Authority and it is only used to issue the Root Certificate for the TFS Labs Domain. It signs the Certificate for the Subordinate Certificate Authority only and is left offline unless there is an issue with the Subordinate Certificate Authority. It is not a member of the TFS Labs Domain and has no additional software or services installed on it. Once the implementation of the Certificate Authority is complete it can be shutdown (but not deleted).
• TFS-CA01 is the Subordinate Certificate Authority and issues all Certificates within the TFS Labs Domain. It also handles the OCSP Role and CRL roles. It is a TFS Labs Domain member.
• TFS-WIN10 is a Workstation that is a member of the TFS Labs Domain, and it is used to ensure Certificates that are issued by the two Certificate Authorities are operating correctly. It is also used to ensure that Group Policy deployment of these certificates are working correctly. This guide assumes that you can configure a Windows 10 Pro Virtual Machine prior to starting this guide.

Certificate Hierarchy Overview

For the Certificates that will be issued for the TFS Labs Domain, there will be one Root and one Subordinate Certificate in a Two-Tier Certificate Authority:

The Validity Period for the Certificates in the TFS Labs Domain is set to the following:

• The Standalone Root CA Certificate is set to expire after 10 years. This Certificate is the Root of the entire PKI at TFS Labs. 10 Years for the Validity Period is perfectly acceptable for a Root CA, and that Server will need to be brought online once every 52 weeks in order to update the CRL for the Subordinate CA.
• The Enterprise Subordinate CA Certificate is set to expire after 5 years. This Certificate is used to Sign all Certificates that are issued to the TFS Labs Domain. Unlike the Root CA, it is always online.
• Any Certificates that are issued from the Enterprise CA is limited to 1 year only. A lot of vendors, the most recent being Apple have specifically restricted SSL lifetimes to 1 year only. This forces Vendors to keep their SSL Certificates up to date, and to make sure that modern security practices and technologies are being used.

Design Considerations

In the deployment of Active Directory Certificate Services on the TFS Labs Domain, the following design considerations will be made:

• The use of SHA-1 will not be used since it has been deprecated by online Certificate Authorities and by virtually every vendor. The Certificate Authority created at TFS Labs will use SHA-2 (SHA256) by default.
• Utilize an Offline Root CA for the main Certificate.
• Utilize a Subordinate Enterprise CA for issuing Certificates to the TFS Labs Domain. This will always be online and will be used to issue all Certificates.
• The Root Certificate will be valid for 10 Years and the Subordinate Certificate will be valid for 5 Years. All issued Certificates from the Subordinate CA will be valid for 1 Year only.
• The Offline Root CA is only online for creating the Enterprise CA and is then shutdown and can isolated from the network in order to keep it safe.
• Any files that need to be transferred to and from the Root CA is to be done with a Virtual Floppy Disk. This will be deleted at the end of the implementation phase and when needed in the future a new one should be created.
• Auditing will be enabled on all Servers that are performing Certificate related tasks. This will write events to the Windows Event Log every time a Certificate is Issued, Revoked, Requested, etc.
• CNAME records will be used when possible in the deployment to allow for the TFS-CA01 Server to be split up in the future if needed.

Why Use an Offline CA?

There are a lot of very good reasons to use an Offline Root CA in your environment and it is pretty much expected in a Certificate Authority that is created today. Unauthorized access to your Certificate Authority can put your organization at risk and can cause a lot of headaches in order to fix it, especially if you depend heavily on a PKI for critical functions in your environment.

The Root CA is critical to your PKI and you don’t want to risk having the Root CA compromised and having your Private Keys leaked. This would effectively invalidate every single Certificate in your organization.

The best way to protect the Root CA is always to have it be completely unavailable to people on the network. It isn’t needed in day to day operations, so having it online is not necessary and can put it at unnecessary risk. This also means that it is not enough to just have it turned off until needed, it shouldn’t be accessible by anyone even when it is temporarily powered on. A lot of administrators don’t even have a network connection to it and use Virtual Floppy Disks to transfer data between it and other Servers. It is cumbersome, but this happens so infrequently that it shouldn’t be an issue. Some Virtualization platforms allow for Copy/Paste, but that should be disabled for the Root CA in order to minimize the attack surface on it.

Registered IANA Number

When you are dealing with an Internal CA you don’t really need to worry about utilizing a properly registered IANA Number. This is only ever required if you are going to be using your Certificate Authority outside of your organization. This is beyond the scope of this guide.

Active Directory Certificate Services Internal URLs

The following URLs will be in use once the Active Directory Certificate Services implementation has been completed.

SSL Enabled Services

SSL is not used for securing many of the Web Sites that a Certificate Server uses. The one exception is the Active Directory Web Enrollment Service, since it is used to securely submit a Certificate Request. This is because you cannot always assume that the device connecting to the HTTPS service has your Certificates on it, and therefore the connection would not be secure anyways.

Disclaimer

I cannot guarantee that this guide will work in your environment and I cannot take responsibility if this guide causes any potential issues in your environment. If you or anyone else has attempted to create a Certificate Authority in the past you should check your Active Directory setup to see if you have any failed Certificate Authorities in there already. You should remove these first before starting this guide.

I cannot guarantee that there are no errors in this guide as well. I have implemented this exact same setup at multiple organizations without any major issues, but odd issues can always arise in a Windows Server Infrastructure. So be prepared to have to “Google” your way out a few error messages in this guide.

As with everything else, you should build this out in a lab at least once prior to attempting this on a production environment. You should not attempt to implement this guide for your organization if you don’t have a good understanding of how a Certificate Authority and PKI works.

• Introduction
• Part 1 — Offline Root CA Setup
• Part 2 — Subordinate CA Setup
• Part 3 — Deploy Root and Subordinate Certificate
• Part 4 — Certificate Revocation Policies
• Part 5 — Configure Private Key Archive and Recovery
• Part 6 — Certificate Template Deployment
• Part 7 — Certificate Auto-Enrollment
• Part 8 — Final Steps

Active Directory Certificate Services Overview

Active Directory Certificate Services (AD CS) allows workstations, servers, and applications to establish trust within an Active Directory forest without the cost of third-party certificates like TLS.

This post shows how to install and configure Active Directory Certificate Services on server 2019.

• Before you install Active Directory Certificate Services, you must name the computer, configure the computer with a static IP address, and join the computer to the domain.
  
• To perform this procedure, the computer on which you are installing AD CS must be joined to a domain where Active Directory Domain Services (AD DS) is installed.

To install Active Directory Certificate Services 

Log on as a member of both the Enterprise Admins group and the root domain’s Domain Admins group. 

In Server Manager, click Manage, and then click Add Roles and Features. The Add Roles and Features Wizard opens.

In Before You Begin, click Next.

In Select Installation Type, ensure that Role-Based or feature-based installation is selected, and then click Next.

In Select destination server, ensure that Select a server from the server pool is selected. In Server Pool, ensure that the local computer is selected. Click Next.

In Select Server Roles, in Roles, select Active Directory Certificate Services. When you are prompted to add required features, click Add Features, and then click Next.

In Select features, click Next.

In Active Directory Certificate Services, read the provided information, and then click Next.

In Role Services, click Certification Authority, and then click Next.

In Confirm installation selections, click Install. Do not close the wizard during the installation process. When installation is complete,

Click Configure Active Directory Certificate Services on the destination server. The AD CS Configuration wizard opens. Read the credentials information and, if needed, provide the credentials for an account that is a member of the Enterprise Admins group. Click Next.

In Role Services, click Certification Authority, and then click Next.

On the Setup Type page, verify that Enterprise CA is selected, and then click Next.

On the Specify the type of the CA page, verify that Root CA is selected, and then click Next.

On the Specify the type of the private key page, verify that Create a new private key is selected, and then click Next.

On the Cryptography for CA page, keep the default settings for CSP (RSA#Microsoft Software Key Storage Provider) and hash algorithm (SHA2), and determine the best key character length for your deployment. Large key character lengths provide optimal security; however, they can impact server performance and might not be compatible with legacy applications. It is recommended that you keep the default setting of 2048. Click Next.

On the CA Name page, keep the suggested common name for the CA or change the name according to your requirements. Ensure that you are certain the CA name is compatible with your naming conventions and purposes, because you cannot change the CA name after you have installed AD CS. Click Next.

On the Validity Period page, in Specify the validity period, type the number and select a time value (Years, Months, Weeks, or Days). The default setting of five years is recommended. Click Next.

On the CA Database page, in Specify the database locations, specify the folder location for the certificate database and the certificate database log. If you specify locations other than the default locations, ensure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next.

In Confirmation, click Configure to apply your selections, and then click Close.

Configuration succeeded, Click Close