Выпуск сертификата 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 Server 2019, вам потребуется ознакомиться с процессом его создания и настройки. В этой статье мы рассмотрим все этапы выпуска и установки сертификата в Windows Server 2019.

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

Примечание: Перед созданием запроса на выпуск сертификата, убедитесь, что у вас установлен и настроен сертификационный центр Windows Server 2019.

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

Получение сертификата Windows Server 2019: подготовка

Для успешного получения сертификата на Windows Server 2019 необходимо выполнить некоторые предварительные действия. Ниже приведены основные шаги, которые необходимо выполнить перед началом процесса получения сертификата:

1. Установите операционную систему Windows Server 2019. Убедитесь, что у вас установлена последняя версия Windows Server 2019. Если у вас уже установлена операционная система, убедитесь, что она обновлена до последней версии.
2. Настройте сетевое подключение. Предварительно настройте сетевое подключение на вашем сервере. Убедитесь, что у вас есть доступ к Интернету и что сервер имеет правильные сетевые настройки.
3. Установите необходимые программы. Для получения сертификата Windows Server 2019 вам может потребоваться установить дополнительное программное обеспечение. Убедитесь, что вы установили все необходимые программы и инструменты.
4. Создайте учетную запись для запроса сертификата. Для успешного получения сертификата вам потребуется создать учетную запись, от имени которой будет отправлен запрос на сертификат. Учетная запись должна иметь необходимые права доступа и разрешения для выполнения данной операции.
5. Подготовьте запрос на сертификат. Перед получением сертификата вам потребуется подготовить запрос на сертификат. Для этого необходимо запустить утилиту для создания запроса на сертификат и заполнить соответствующие поля.

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

Создание учетной записи Windows Server 2019

Для работы с Windows Server 2019 вам потребуется создать учетную запись, которая позволит вам получить доступ к серверу и управлять его функциями. Этот процесс достаточно простой и состоит из нескольких шагов.

1. Зайдите на сервер с помощью учетной записи администратора или другой учетной записи с правами администратора.

2. Откройте Панель управления и перейдите в раздел «Учетные записи пользователей».

3. Нажмите на кнопку «Создать новую учетную запись» и следуйте инструкциям на экране.

4. Задайте имя пользователя и пароль для новой учетной записи. Убедитесь, что пароль достаточно сложный и надежный.

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

6. Нажмите на кнопку «Создать» и подождите, пока процесс создания учетной записи завершится.

Теперь вы можете использовать новую учетную запись для входа на сервер и выполнения административных задач.

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

Установка необходимого программного обеспечения

Перед началом процесса установки сертификата Windows Server 2019 необходимо убедиться, что на компьютере установлено необходимое программное обеспечение.

Ниже приведены основные компоненты, которые вам понадобятся:

1. Операционная система Windows Server 2019.
2. Драйверы для всех устройств сервера, включая сетевые карты, контроллеры RAID и другие.
3. Microsoft .NET Framework 4.7.2 или более поздняя версия.
4. Microsoft Management Console (MMC).
5. Active Directory Certificate Services (AD CS).

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

После установки всех необходимых компонентов вы будете готовы начать процесс выпуска сертификата Windows Server 2019.

Генерация запроса на сертификат Windows Server 2019

В Windows Server 2019 для генерации запроса на сертификат можно использовать MMC (Microsoft Management Console). Для этого необходимо выполнить следующие действия:

1. Откройте MMC, нажав клавишу «Win + R» и введя команду «mmc».
2. В меню «Файл» выберите «Добавить/удалить контрольные панели», затем выберите «Сертификаты» и нажмите кнопку «Добавить».
3. Выберите опцию «Компьютеров управления» и нажмите кнопку «Далее».
4. Выберите опцию «Локальный компьютер» и нажмите кнопку «Закончить».
5. В окне MMC выберите раздел «Личные сертификаты», щелкните правой кнопкой мыши и выберите «Все задачи» -> «Запросить новый сертификат».

После выполнения этих действий откроется мастер запроса на сертификат. В нем необходимо выбрать тип сертификата, заполнить информацию о субъекте (например, название организации, имя сервера и т.д.) и указать место сохранения запроса на сертификат. Можно также добавить дополнительные атрибуты субъекта, если это необходимо.

После заполнения всех необходимых полей необходимо нажать кнопку «Завершить», чтобы создать запрос на сертификат. Затем можно отправить этот запрос в удостоверяющий центр (CA) для выпуска сертификата.

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

Установка и настройка службы Certificate Authority

Для установки службы Certificate Authority на Windows Server 2019 необходимо выполнить следующие шаги:

Шаг 1: Установка роли Certificate Services

1. В Server Manager выберите «Управление» и нажмите на «Добавить роли и компоненты».

2. В мастере установки выберите «Установить роли и компоненты независимо от других серверов».

3. Найдите роль «Центр сертификации» и установите ее.

Шаг 2: Конфигурация службы Certificate Authority

1. В Server Manager выберите «Управление» и перейдите в «Центр администрирования Certificate Services».

2. В разделе «Опции CA» выберите «Настроить новый Центр сертификации».

3. Выберите тип Центра сертификации, например, «Enterprise CA».

4. Укажите имя и параметры Центра сертификации.

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

Шаг 3: Проверка и настройка службы Certificate Authority

1. После установки и настройки Центра сертификации проверьте его работоспособность.

2. Удостоверьтесь, что службы Certificate Authority запущены и работают без ошибок.

3. Проверьте настройки, доступные сертификаты и другие параметры.

После успешной установки и настройки службы Certificate Authority можно приступить к выпуску и управлению сертификатами цифровой подписи на сервере Windows Server 2019.

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

— Advertisement —

Hi. How are you? Let’s continue exploring the features of Windows Server 2019. In this opportunity, we will talk about how to create self signed certificates on Windows Server 2019. In the first place let’s define what is an SSL (Secure Socket Layer) Certificate. It encrypts all data between the server and the client’s browser. Consequently, if an attacker wants to access the information exchanged between the two, he won’t be able to decipher it. As you can see, it is a fundamental aspect of the security of a website. In addition, it is indispensable to be able to activate HTTPS on the site.

Generating SSLcertificates

On the other hand, there are several sites online to acquire these certificates: comodo, Symantec and GlobalSign for example. These sites offer SSL certificates at different prices, depending on the customer’s needs. However, we have the possibility to generate self-signed certificates using Windows Server 2019. For this, we will use Internet Information Services, if you don’t know how to activate it, go through our tutorial. Obviously, the effectiveness of a self-signed certificate is less than that of one signed by a company. However, we can use these certificates to work on our intranet or publish sites on the Internet as well. So let’s see how to create self signed certificates on Windows Server 2019.

Create self signed certificates using IIS manager

From the Server Manager, locate IIS in the left pane.

Then right-click on the server and run the IIS manager

Click on the name of the server in the left column connections. Then double click on Server Certificates

In the right column, select Create Self-Signed Certificate.

Choose the name of your preference to identify the certificate and press OK to continue.

Finally, we have a certificate valid for one year. We can see it in the section Server Certificates

Testing the certificate.

To test the performance of the certificate we just created, we will open the IIS Manager.

Next, press the Add button.

In the next window, click on Type and select https, then on SSL Certificate choose the newly created certificate and press OK to continue.

We should now see the bindings for port 443. Next, press the Add button. Now close the window to finish.

All right, let’s try the new certificate. In the IIS Manager, go to the Action panel on the right and select Browse *.443 (https).

We’ll immediately see a security alert. This is because the browser cannot verify the authenticity of the certificate since the website is the one that provides the information. We must establish an exception to this alert by clicking on advanced, and then on Accept the risk and continue.

Once this is done, we’ll see the https navigation enabled on the website.

Conclusion

We have seen how to generate a self-signed certificate in Windows Server 2019. As we already mentioned, this will be of great help to the security of our websites. I hope you enjoyed this tutorial, in next releases, we will continue studying on Windows Server 2019. In fact, let’s see how to generate error-free SSL certificates for local development. In conclusion, has been a profitable way up to here, before saying goodbye I want to invite you to join our group on Facebook.

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.

The Server that will be hosting the Offline Root Certificate Authority requires minimal resources in order to operate. It is only to ever be used for issuing Subordinate Certificates to other TFS Labs Domain Servers and is also used to revoke or add new Subordinate Certificates if necessary. It is also used to refresh the CRL at least once a year.

The Server is setup as a standalone Windows Server and is never meant to be a member of an Active Directory Domain or even have any network connections to it. This means that it will require some local Security modifications that are normally handled through Group Policy from Active Directory. Since there is no connection to Active Directory, these changes will need to be applied locally.

Since there are no Network Connections to and from this Virtual Machine, create a Virtual Floppy Disk that will be used for transferring files to and from the TFS-ROOT-CA Server. Name the file RootCAFiles (the file extension will vary based on whether you are using Hyper-V, VirtualBox or VMware) and store it in a location that will be available for all Virtual Machines that are being used. The first time that it is inserted into one of the Virtual Machines it will need to be formatted with the default settings.

Provision and configure a new Virtual Machine using the following settings:

1. Create a new Virtual Machine with the following settings:
   • Virtual CPU — 1
   • Virtual Memory — 4096 MB
   • Virtual Hard Disk — 60 GB
   • Virtual Floppy Drive — 1
   • Virtual Network Adapters — 0
2. Install Windows Server 2019 Standard (Desktop Experience) with the default options.
3. Set the hostname of the Server to TFS-ROOT-CA. Set it to be a member of the TFS-CA Workgroup instead of a Domain.
4. Secure the local Administrator Account and additional User Accounts on the TFS-ROOT-CA Server:
   • Use a complex password for the Administrator Account and store it securely.
   • Ensure that there are no additional user accounts present on the Server. The Guest account should already be disabled by default and will be renamed in a further step in this guide.
   • The Administrator account will be renamed to CA-Admin at a further step in this guide.
5. There is no need to activate the Windows Server license, or even input a license key (make sure you are licensed though). If activation is ever needed on this Server, then the telephone option would be required in order to accomplish this since there is no network connection on this Server.
6. On the root of the C:\ Drive create a folder called RootCA (C:\RootCA). This folder will store the Root Certificate, Subordinate Certificate and other necessary Certificate Files that are needed during the entire implementation process.
7. Insert the RootCAFiles Virtual Floppy Disk into the Virtual Floppy Drive. Format the floppy disk with the default settings. Eject the disk when completed.
8. Open the Local Group Policy Editor Console (gpedit.msc), confirm the following settings, and make any changes if necessary:
   • Modify the Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options settings to match the following:
     • Accounts: Administrator account status — Enabled
     • Accounts: Block Microsoft accounts — Users can’t add or log on with Microsoft Accounts
     • Accounts: Guest account status — Disabled
     • Accounts: Limit local account use of blank passwords to Console logon only — Enabled
     • Accounts: Rename administrator account — CA-Admin
     • Accounts: Rename guest account — Administrator
     • Interactive Logon: Don’t display last signed-in — Enabled
     • Interactive Logon: Don’t display username at sign-in — Enabled
     • Network security: Do not store LAN Manager hash value on next password change — Enabled
     • Network security: LAN Manager authentication level — Send NTLMv2 response only. Refuse LM & NTLM
9. Open the Local Security Policy Console (secpol.msc), confirm the following settings, and make any changes if necessary:
   1. Modify the Security Settings > Account Policies > Password Policy settings:
      • Enforce password history — 24 passwords remembered
      • Maximum password age — 90 days
      • Minimum password age — 1 days
      • Minimum password length — 14 characters
      • Password must meet complexity requirements — Enabled
      • Store passwords using reversible encryption — Disabled
   2. Modify the Security Settings > Account Policies > Account Lockout Policy settings:
      • Account lockout threshold — 5 invalid login attempts
      • Account lockout duration — 30 minutes
      • Reset account lockout counter after — 30 minutes
10. Restart the TFS-ROOT-CA Server to apply the updated security settings.
11. Optional: Enable BitLocker in order to secure the TFS-ROOT-CA Virtual Machine while it is powered off or being stored in another location:
    1. Open the Server Manager Console (servermanager.exe), click on the Manage menu, and click on Add Roles and Features to start the installation wizard.
    2. On the Before You Begin screen, click the Next button to continue.
    3. On the Installation Type screen, select the option for Role-based or feature-based installation and click the Next button to continue.
    4. On the Server Selection screen, verify that the TFS-ROOT-CA Server is selected and click the Next button to continue.
    5. On the Server Roles screen, click the Next button to continue.
    6. On the Features screen, select the BitLocker Drive Encryption Feature. The installation wizard will ask to install the necessary management tools for the role. Click the Add Features button to continue.
    7. On the Features screen, click the Next button to continue.
    8. On the Confirmation screen, select the option to Restart the destination server automatically if required. When prompted with a warning about restarting the Server, click the Yes button (the Server must restart in order to continue). Click the Install button to continue.
    9. Once the TFS-ROOT-CA Server has restarted click the Close button on the Installation Progress screen.
    10. Open the Local Group Policy Editor Console (gpedit.msc) and modify the Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives settings to match these settings:
        • Require additional authentication at startup — Enabled
        • Allow BitLocker without a compatible TPM (requires a password or a startup key on a USB flash drive) — Enabled
        • Configure TPM startup: Allow TPM
        • Configure TPM startup PIN: Allow startup PIN with TPM
        • Configure TPM startup key: Allow startup key with TPM
        • Configure TPM startup key and PIN: Allow startup key and PIN with TP
    11. Insert the RootCAFiles Virtual Floppy Disk.
    12. Open File Explorer and go to This PC. Right-click on the C:\ Drive and select Turn on BitLocker.
    13. On the BitLocker Drive Encryption setup screen click the Next button to continue.
    14. On the Preparing your drive for BitLocker screen click the Next button to continue.
    15. On the BitLocker Drive Encryption setup screen, click the Next button to continue.
    16. On the Choose how to unlock your drive at startup screen, select the option to Enter a password.
    17. On the Create a password to unlock this drive screen, enter the password that you want to use to unlock the drive at boot up. Make sure that you do not forget this password as it will require the Recovery Keys in order to get back into the TFS-ROOT-CA Virtual Machine. Ensure that you use a complex password for this and make it at least 14 characters in length. Click the Next button to continue.
    18. On the How do you want to back up your recovery key? screen, select the option to Save to a file. Save the file to the A:\ Drive (floppy disk). Click the Next button to continue.
    19. Eject the RootCAFiles Virtual Floppy Disk and then backup the recovery key to another device before you continue. This is critical in case there is an issue with the BitLocker password.
    20. On the Choose how much of your drive to encrypt screen, select the option to Encrypt entire drive (slower but best for PCs and drives already in use) and click the Next button.
    21. On the Choose which encryption mode to use screen, select the option for New encryption mode (best for fixed drives on this devices) and click the Next button to continue.
    22. On the Are you ready to encrypt this drive? screen, ensure that the Run BitLocker system check box is selected and then click the Continue button.
    23. When prompted, restart the TFS-ROOT-CA Server.
    24. Enter the password that you set for the drive to ensure that it is working correctly.
    25. Login to the TFS-ROOT-CA Server, you should receive a notification that the drive is encrypting. You can also check the status of BitLocker at anytime by going to File Explorer, then to This PC, right-clicking on the C:\ Drive and selecting the Manage BitLocker option.

1.2 Root CA CAPolicy.inf Installation

The CAPolicy.inf file is used to add configuration details to the Certificate at the time of creation. Create a file in the C:\Windows folder called CAPolicy.inf (ensure that it is saved with the inf extension and not the txt extension, otherwise these settings will be ignored). Copy the following contents into this file:

[Version]
Signature=”$Windows NT$”

[PolicyStatementExtension]
Policies=AllIssuancePolicy,InternalPolicy
Critical=FALSE

; AllIssuancePolicy is set to the OID of 2.5.29.32.0 to ensure all Certificate templates are available.
[AllIssuancePolicy]
OID=2.5.29.32.0

[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="The TFS Labs Certification Authority is an internal resource. Certificates that are issued by this Certificate Authority are for internal usage only."
URL=http://pki.corp.tfslabs.com/cps.html

[Certsrv_Server]
; Renewal information for the Root CA.
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10

; Disable support for issuing Certificates with the RSASSA-PSS algorithm.
AlternateSignatureAlgorithm=0

; The CRL publication period is the lifetime of the Root CA.
CRLPeriod=Years
CRLPeriodUnits=10

; The option for Delta CRL is disabled since this is a Root CA.
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0

Note: You can update the OID number in the InternalPolicy section for your deployment if it is required. The OID number in this example is used in Microsoft examples, but it should work for your organization if it is only ever going to be used internally. You can register for one if you would like to through IANA.

Signature Algorithm Support Issues

The AlternateSignatureAlgorithm=0 flag in the CAPolicy.inf file explicitly uses SHA256 for the algorithm instead of RSASSA-PSS. This can cause issues with some devices (especially iOS) and by ensuring that it is disabled you shouldn’t have issues with these certificates.

1.3 Active Directory Certificate Services Role Installation

Once the TFS-ROOT-CA Server has been installed and configured properly, the Active Directory Certificate Services Role needs to be installed.

1. Open the Server Manager Console (servermanager.exe), click on the Manage menu, and click on Add Roles and Features to start the installation wizard.
2. On the Before You Begin screen, click the Next button to continue.
3. On the Installation Type screen, select the option for Role-based or feature-based installation and click Next to continue.
4. On the Server Selection screen, verify that the TFS-ROOT-CA Server is selected and click Next.
5. On the Server Roles screen, select the Active Directory Certificate Services option. The installation wizard will ask to install the necessary management tools for the role. Click the Add Features button to continue.
6. On the Server Roles screen, click the Next button to continue.
7. On the Features screen, click the Next button to continue.
8. On the Active Directory Certificate Services screen, click the Next button to continue.
9. On the Role Services screen, select the option for Certification Authority and click the Next button to continue.
10. On the Confirmation screen, select the option to Restart the destination server automatically if required. When prompted with a warning about restarting the Server, click the Yes button (the Server must restart in order to continue). Click the Install button to continue.
11. Once the installation is completed, click the Close button.

1.4 Active Directory Certificate Services Role Configuration

Once the Active Directory Certificate Services Role has been added, it will need to be configured. In the process of configuring the role for the TFS Labs Domain, the following Root Certificate will be created:

1. To begin the configuration of Active Directory Certificate Services on TFS-ROOT-CA, open the Server Manager Console (servermanager.exe). Click the Notifications icon in the upper-right hand corner and click the Configure Active Directory Certificate Services on the destination server link in the Post-deployment Configuration box.
2. On the Credentials screen, verify that the Administrator credentials is set to TFS-ROOT-CA\CA-Admin and click Next to continue.
3. On the Role Services screen, select the option for Certification Authority and click the Next button to continue.
4. On the Setup Type screen, the option for Standalone CA should be selected. The option for Enterprise CA is not available since this Server is not a Domain Member Server. Click the Next button to continue.
5. On the CA Type screen, ensure that the Root CA option is selected (the Subordinate CA option will be used later for the Enterprise CA). Click the Next button to continue.
6. On the Private Key screen, verify that the Create a new private key option is selected. This is because this a new CA installation and the Private Key is not being restored from a previous Server. Click the Next button to continue.
7. On the Cryptography for CA screen, make the following changes and then click the Next button to continue:
   • Cryptographic Provider: RSA#Microsoft Software Key Storage Provider
   • Key Length: 4096
   • Hash Algorithm: SHA256
8. On the CA Name screen, set the Common Name (CN) for the CA to TFS Labs Certificate Authority and click the Next button to continue.
9. On the Validity Period screen, set the validity period to 10 Years and click the Next button to continue.
10. On the CA Database screen, make no changes to the database location and click the Next button to continue.
11. On the Confirmation screen, verify that the options are correct and click the Configure button to commit the changes.
12. On the Results screen, click the Close button.

Certificate Validity Period

It is not advised to have the Root Certificate and the Subordinate Certificate set to have the same Validity Period. For example, if both Certificates have a 5 Year expiration date, it is possible that the Root Certificate will expire before the Subordinate Certificate since it was signed first. If this happens it will be extremely difficult to re-sign both Certificates because they will both be invalid at the same time.

1.5 Root Certificate Authority CRL Configuration

The CRL Configuration for the Root CA is configured in this step to give greater control over when this takes place, and the time is extended to 52 weeks since the CRL does not need to be updated often on the Root CA. It also ensures that the Subordinate CA lifetime is extended from 1 Year to 5 Years.

Active Directory Configuration Partition Distinguished Name

To determine what the correct format of this name would be for your domain you can check it in only a few steps.

1. On one of your Domain Controllers, open the Active Directory Users and Computers Console (dsa.msc).
2. Go to the View menu and select Advanced Features.
3. Right-click on the root of your Domain and select Properties.
4. Go to the Attribute Editor tab.
5. Scroll down until you find the distinguishedName Attribute Field and click the View button.
6. Copy the value in the Attribute Field, this is the information needed for Step 2 below.

Once the Active Directory Configuration Partition Distinguished Name has been determined, the rest of the configuration can continue.

1. Open an Administrative Command Prompt.
2. To define the Active Directory Configuration Partition Distinguished Name, run the following command:

Certutil -setreg CA\DSConfigDN "CN=Configuration,DC=corp,DC=tfslabs,DC=com"

1. To define Validity Period Units for all issued certificates by this CA, run following commands:

Certutil -setreg CA\ValidityPeriodUnits 5
Certutil -setreg CA\ValidityPeriod "Years"

1. To define CRL Period Units and CRL Period, run the following commands:

Certutil -setreg CA\CRLPeriodUnits 52
Certutil -setreg CA\CRLPeriod "Weeks"

1. To define CRL Overlap Period Units and CRL Overlap Period, run the following commands:

Certutil -setreg CA\CRLOverlapPeriodUnits 12
Certutil -setreg CA\CRLOverlapPeriod "Hours"

1. Restart the Active Directory Certificate Services service:

net stop CertSvc
net start CertSvc

CRL Renewal Period

As defined in Step 4 in Section 1.5, the CRL Period on the Root CA is set to 52 weeks. This means that every 52 weeks you will need to power on the TFS-ROOT-CA Server and renew the CRL. You should set a reminder in your calendar to do perform this task every 50 weeks to ensure that it is renewed in time.

1.6 Enable Auditing on the Root Certificate Authority

Auditing is needed on any Server running Active Directory Certificate Services. This will write logs to the Windows Event Log whenever a Certificate is issued or revoked.

1. Open the Local Security Policy Console (secpol.msc) and modify the Security Settings > Local Policies > Audit Policy > Audit object access setting to audit Success and Failure.
2. Enable auditing for the Certificate Authority by running the following command from an Administrative Command Prompt:

Certutil -setreg CA\AuditFilter 127

1. Restart the Active Directory Certificate Services Service.

1.7 Root Certificate Authority CDP and AIA Configuration

Before the Subordinate Certificate Authority can be properly configured, the Certificate Revocation List needs to be configured on the Root CA Certificate. This configuration will be present in the Subordinate Certificate that will be issued on the Enterprise CA which will be installed on the TFS-CA01 Server.

1. Open the Certification Authority Console (certsrv.msc) for the TFS-ROOT-CA Server.
2. Right-click on TFS Labs Certificate Authority Server and select Properties.
3. On the Extensions tab, verify that the CRL Distribution Point (CDP) extension is selected and click the Add button.
4. Under the Location field, enter the following address and click the OK button:

http://pki.corp.tfslabs.com/CertData/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

1. Back on the Extensions tab, verify that the Include in CRLs. Clients use this to find Delta CRL locations. and Include in the CDP extension of issued certificates options are selected for the location that was just entered.
2. Select the file:///CertEnroll/TFS%20Labs%20Certificate%20Authority.crl list item and click the Remove button. Click the Yes button to confirm that you want to remove the location.
3. On the Extensions tab, verify that the Authority Information Access (AIA) extension is selected and click the Add button.
4. Under the Location field, enter the following address and click the OK button:

http://pki.corp.tfslabs.com/CertData/<ServerDNSName>_<CaName><CertificateName>.crt

1. Back on the Extensions tab, verify that the Include in the AIA extension of issued certificates option is selected for the location that was just entered.
2. Select the file:///CertEnroll/_.crt list item and click the Remove button. Click the Yes button to confirm that you want to remove the location.
3. Click the OK button to commit the changes. When prompted to restart Active Directory Certificate Services, click the Yes button.
4. Verify that the settings are correct by running the following commands in an Administrative Command Prompt:

Certutil -getreg CA\CRLPublicationURLs
Certutil -getreg CA\CACertPublicationURLs

1. In the Certification Authority Console (certsrv.msc), right-click on Revoked Certificates under TFS Labs Certificate Authority and select All Tasks > Publish.
2. On the Publish CRL window, verify that New CRL is selected and click the OK button.
3. Close the Certification Authority Console.

1.8 Root Certificate and CRL List Export

Exporting the Root Certificate CRL List is needed in order to make it available on the TFS-CA01 Server. The links to these files were referenced in the Certificate configuration, so they will need to be copied to the Subordinate CA Server for users to access these files.

1. Add the RootCAFiles Virtual Floppy Disk to the TFS-ROOT-CA Virtual Machine.
2. Copy the contents of the C:\Windows\System32\CertSrv\CertEnroll folder to the C:\RootCA folder.
3. Open the Certificates Console (certlm.msc) under the Local Computer Account and export the TFS Labs Certificate Authority Certificate from the Trusted Root Certification Authorities Store as a DER encoded binary. Save the file as C:\RootCA\TFS Labs Certificate Authority.cer.
4. Copy the contents of the C:\RootCA folder to the A:\ Drive. The contents of the A:\ Drive should be the following:

A:\TFS Labs Certificate Authority.cer
A:\TFS Labs Certificate Authority.crl
A:\TFS-ROOT-CA_TFS Labs Certificate Authority.crt

1. Eject the RootCAFiles Virtual Floppy Disk.

Certificate Authority in Windows Server 2019

• 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