Развивающие игры для детей для windows

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

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

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

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

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

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

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

• VPN-сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows Server 2003

Windows Server 2008 R2

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

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

Установка и настройка Удостоверяющего Центра на базе Windows Server

1)Изменим имя сервера (Computer name) — Панель управления\Система и безопасность \ Система

и установим крипто провайдера CSPSetup-4.0.9842.exe

Перезагружаем компьютер
После установки Microsoft CA изменить имя сервера нельзя.
2)Добавляем Роль сервис через оснастку Диспетчер серверов (Server Manager)

2.1)Выбираем сервер

2.2)Роли сервера:Отмечаем Веб-сервер (IIS) , Службы сертификатов Active Ditectory (active directory certificate services)

2.3)Службы ролей: Отмечаем Служба регистрации в центре сертификации через Интернет (Online Certificate Authority Registration Service)

2.4)Подтверждение нажимаем кнопку Установить

3)Диспетчер серверов \ Настройка службы сертификатов Active directory

3.1)Службы ролей отметим: Центр сертификации , Служба регистрации в центре сертификации Интернет

3.2)Вариант установки — Автономный ЦС

3.3)Укажите тип ЦС — Корневой ЦС

3.4)Укажите тип закрытого ключа — Создать новый закрытый ключ

3.5)Шифрование для ЦС crypto-pro gost r 34.10-2012 cryptographic service provider 512
Отметить Разрешить взаимодействие с администратором , если ЦС обращается к закрытому ключу

3.6)Закрытый ключ ,заполняем Имя ЦС

3.7)Срок действия — укажите период действия корневого сертификата , водить мышкой при запросе

3.8)Выберете устройство\место хранение сертификата и задайте пароль

3.9)КриптоПро csp Установить новый пароль , запомнить пароль

4.0)Настройка установка Службы сертификации Active Diretory завершена

4.1)Диспетчер служб IIS — Сертификат сервера

4.2)Создать самозаверенн ый сертификат.. указать имя — web

4.3)Сайты Default Web Site , Привязки.. добавить тип httpS , SSL-сертификат web

5)Настройка Центр сертификации crtsrv
CRL Distribution Points (CDP) Списки отзывов сертификатов
Authority Information Access (AIA) Сведения о центрах сертификации

Отметить Включить в CRL . Клиенты используют для поиска в размещениях Delta CRL , Включать в CDP-расширения выданных сертификатов

5.1)Настройка политики выдачи сертификатов — по умолчанию требуется подтверждение администратора

6)Выпуск \ получение сертификата через веб интерфейс httpS://msk01-ca/certsrv/

Запрос сертификата\Расширенный запрос сертификата\Создать и выдать запрос к этому ЦС

Примечание:

Для возможности дальнейшего выбора криптопровайдера “КриптоПро CSP” в окне создания запроса на сертификат, выполните следующее:

в файле System32\certsrv\certsgcl.inc измените значение константы Const  nMaxProvType с 25 на 99. В стандартном скрипте перечислено только 25 типов криптопровайдера.

https://www.youtube.com/channel/UCnu9HxldaUZZg_DzCKcK23w/ https://www.youtube.com/watch?v=_SOIUW22e-o

Сравнение версий КриптоПро CSP
https://www.cryptopro.ru/products/csp/compare
рекомендуется ставить последнюю версию , с обновлениями

КриптоПро 4 ошибки в журнале событий Windows

https://forsenergy.com/ru-ru/certsvr/html/18656667-17b6-4e81-af4c-4ff1b767c8b8.htm
Задание точек распространения CRL в выданных сертификатах
Откройте оснастку «Центр сертификации».
В дереве консоли щелкните имя центра сертификации.
В меню Действие выберите команду Свойства, а затем выберите вкладку Расширения . Убедитесь, что значение Выберите расширение равно Точка распространения списков отзыва (CDP).
Выполните одно из следующих действий. (Список точек распространения CRL находится в списке Укажите, откуда пользователи могут получить списки отзыва сертификатов (CRL).)
Чтобы указать, что нужно использовать URL-адрес в качестве точки распространения CRL, выполните следующие действия.
Щелкните точку распространения CRL, установите флажок Включать в CDP-расширение выданных сертификатов , а затем нажмите кнопку ОК.
Чтобы указать, что URL-адрес нужно использовать в качестве точки распространения разностных CRL, выполните следующие действия.
Щелкните точку распространения CRL, установите флажок Публикация разностных CRL по адресу , а затем нажмите кнопку ОК.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И нажимаем Next;

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

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

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

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

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

И нажимаем Next;

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

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

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

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

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

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

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

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

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

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

И нажимаем Next;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И нажимаем Next;

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

И нажимаем Next;

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

И нажимаем Next;

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

И нажимаем Next;

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

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

И нажимаем Next;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

certreq -retrieve 2 C:\SubCA.crt

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

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

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

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

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

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

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

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

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

certutil -installcert C:\install\SubCA.crt

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

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

Итог

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

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

Введение

Само-подписанные ssl-сертификаты бывают нужны в некоторых случаях:

• При работе с тестовыми веб-серверами. Когда вам всё равно требуется протокол https. Или не требуется, но вам просто хочется использовать https вместо http. То удобно иметь свой центр сертификации и для каждого тестового сайта выпускать ssl-сертификаты.
• При работе с внутренними web-серверами. Если у компании есть свой внутренний сайт или веб-приложение. И этот сайт доступен только из внутренней сети компании. То, вероятно, вам захочется использовать протокол https вместо http. А так как доступ к сайту есть у ограниченного числа компьютеров, то на них можно добавить свой корневой ssl-сертификат. И тогда, эти компьютеры начнут доверять внутренним сайтам компании.

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

На этом скриншоте, браузер не доверяет сайту, но если нажать на кнопку «Дополнительные«, то вы всё равно сможете перейти на сайт:

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

В этой статье я проделаю следующее:

• На Debian 11 установлю apache2 и настрою его работу на https (с сертификатами по умолчанию для localhost).
• Покажу что клиенты пока не доверяют этому сертификату.
• Создам центр сертификации на этом же сервере. А именно:
  • создам закрытый корневой ключ и открытый корневой ключ (он же корневой сертификат);
  • с помощью этой пары ключей буду выпускать сертификаты для доменов;
  • установлю выпущенный корневой сертификат на компьютер клиента (на windows);
  • с помощью корневого ключа и сертификата, я выпущу ключ и сертификат для домена (для веб-сервера).
• Затем я настрою apache2 на использование созданных мною закрытого ключа и сертификата для веб-сервера. И продемонстрирую вам что клиентский браузер начал доверять сертификату сайту.
• Дальше я установлю и настрою другой веб-сервер — nginx. Настрою его на работу по протоколу https. И продемонстрирую доверие браузера к сайту.

Устанавливаю apache2

Устанавливаю web-сервер apache2:

$ sudo apt install apache2

Настраиваю его работу по протоколу https:

$ sudo a2enmod ssl
$ sudo a2ensite default-ssl.conf
$ sudo systemctl restart apache2

Проверяю доверие к ssl-сертификату сайта, открыв его по https:

Как видите, доверия нет.

Создаю центр сертификации

Теория

Протокол HTTPS это объединение протоколов HTTP + SSL/TLS. А протокол TLS это асинхронное шифрование. То есть создаётся пара ключей. И то, что один ключ может зашифровать, другой может расшифровать и наоборот. В протоколе HTTPS эти ключи не равнозначные:

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

А ещё протокол TLS позволяет создавать цепочки сертификатов. То-есть, если браузер доверяет родительскому сертификату, то он автоматически будет доверять и всем дочерним сертификатам. А чтобы создать дочернюю пару ключей, нужно иметь доступ к родительской паре ключей.

Корневая пара ключей обычно не подтверждает никакой домен. А используется для создания промежуточных сертификатов или сертификатов для доменов (для web-серверов).

Обычно, когда создают ssl-сертификат для домена, то для безопасности отнимают у него право создания дочерних сертификатов.

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

Сервер на котором создают корневые сертификаты, а затем с их помощью выпускают сертификаты для доменов называют — центр сертификации.

Создаю корневой закрытый ключ

Для создания ssl/tls сертификатов можно использовать утилиту openssl, она не требует админских прав.

Создаю корневой закрытый ключ:

$ openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc
   ....................................+++++
   ......................+++++
   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:

Разберу эту команду:

• genpkey — команда для создания закрытого ключа;
• -algorithm RSA — алгоритм асинхронного шифрования, именно он используется для выделения открытого ключа из этого закрытого;
• -out rootCA.key — получаемый файл закрытого ключа;
• -aes-128-cbc — алгоритм симметричного шифрования, которым мы зашифруем файл закрытого ключа с помощью пароля. Пароль нужно будет ввести.

Создаю корневой сертификат

Теперь создаю корневой сертификат (открытый ключ):

$ openssl req -x509 -new -key rootCA.key -sha256 -days 3650 -out rootCA.crt
   Enter pass phrase for rootCA.key:
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [AU]:RU
   State or Province Name (full name) [Some-State]:Moscow
   Locality Name (eg, city) []:Moscow
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:Sysadminium
   Organizational Unit Name (eg, section) []:.
   Common Name (e.g. server FQDN or YOUR name) []:Sysadminium

Разберу команду:

• req — создаёт сертификаты или запросы на сертификаты;
• -x509 — будем создавать сертификат а не запрос;
• -new — создаём новый сертификат (нужно будет ввести значения некоторых полей в сертификате);
• -key rootCA.key — используемый закрытый ключ, из которого нужно создать открытый;
• -sha256 — алгоритм хеширования, чтобы создать подпись ключа;
• -days 3650 — выпускаем сертификат на 10 лет (обратите внимание что закрытые ключи не имеют срока жизни а сертификаты имеют);
• -out rootCA.crt — получаемый сертификат.

Итак, я создал пару ключей:

$ ls -l root*
-rw-r--r-- 1 alex alex 1306 сен  9 11:26 rootCA.crt
-rw------- 1 alex alex 1874 сен  9 11:19 rootCA.key

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

Создаю файл порядковых номеров для выпуска сертификатов, в нём следует указать два нуля:

$ nano rootCA.srl
00

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

Установка корневого сертификата на Winows

Устанавливаются сертификаты на Windows очень просто. Дважды щелкаем по сертификату и открывается окно с его свойствами. Дальше нажимаем на кнопку «Установить сертификат«:

Установить можно для текущего пользователя или для всего компьютера. Так как у меня это тестовая установка, я выберу «Текущий пользователь«:

После нажатия на кнопку «Далее» нужно выбрать «Поместить все сертификаты в следующее хранилище» и нажать кнопку «Обзор«:

В открывшемся окне выбираем «Доверенные корневые центры сертификации«:

Затем нажимаем кнопку «ОК«, «Далее» и «Готово«.

И наконец, подтверждаем установку сертификата:

И затем нужно будет ещё раз нажать кнопку «ОК«.

Если вы еще раз откроете свойства сертификата (двойным щелчком по нему), то увидите что система начала ему доверять:

Создаю ключ и сертификат для домена

Теперь, с помощью корневых ключей мы можем создать ключи для домена. У меня будет домен — site.sysadminium.ru.

Утилита openssl не может без конфигурационного файла добавлять некоторые поля. А нам нужно будет в сертификат добавить поле subjectAltName. Без этого поля браузер Chrome не доверяет сертификату.

Поэтому вначале я создаю следующий конфиг:

$ nano sysadminium.cnf
[ req ]
default_bits = 2048
distinguished_name  = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
countryName                  = Country Name (2 letter code)
countryName_default          = RU
stateOrProvinceName          = State or Province Name (full name)
stateOrProvinceName_default  = Moscow
localityName                 = Locality Name (eg, city)
localityName_default         = Moscow
organizationName             = Organization Name (eg, company)
organizationName_default     = Sysadminium
commonName                   = Common Name (eg, YOUR name or FQDN)
commonName_max               = 64
commonName_default           = site.sysadminium.ru

[ req_ext ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName          = DNS:site.sysadminium.ru

В блоке [ req ] — настраивается команда req:

• default_bits = 2048 — длина ключа по умолчанию.
• distinguished_name = req_distinguished_name — distinguished_name — это поля в сертификате, например Common Name, organizationName и другие. Для этих полей мы создадим блок req_distinguished_name ниже.
• req_extensions = req_ext — расширение для req, здесь мы можем добавить дополнительные поля в сертификат. А в этом параметре мы просто указываем что ниже будет блок req_ext с дополнительными полями.

Блок [ req_distinguished_name ] — служит для конфигурации полей сертификата.

А блок в блок [ req_ext ] — можно добавить некоторые расширяющие свойства сертификата:

• basicConstraints = CA:FALSE — полученные сертификаты нельзя будет использовать как центр сертификации. Другими словами, забираем у сертификатов для доменов право создавать дочерние сертификаты.
• keyUsage = nonRepudiation, digitalSignature, keyEncipherment — созданный ключ будет иметь следующие свойства: неотказуемость (если ключом что-то подписали то аннулировать подпись невозможно), цифровая подпись (сертификат можно использовать в качестве цифровой подписи), шифрование ключей (сертификат можно использовать для симметричного шифрования). Об этих свойствах на английском хорошо написано здесь.
• subjectAltName = DNS:site.sysadminium.ru — а здесь указываем поле subjectAltName и его значение. Как я уже говорил, без этого поля браузер Chrome не доверяет сертификату.

Создаю закрытый ключ для домена

Теперь я создам закрытый ключ для домена:

alex@deb-11:~$ openssl genpkey -algorithm RSA -out site.key
   .......................................+++++
   .............+++++

Создаю файл запроса для домена

С помощью закрытого ключа для домена создаю файл запроса на сертификат:

$ openssl req -new -key site.key -config sysadminium.cnf -reqexts req_ext -out site.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [RU]:
State or Province Name (full name) [Moscow]:
Locality Name (eg, city) [Moscow]:
Organization Name (eg, company) [Sysadminium]:
Common Name (eg, YOUR name or FQDN) [site.sysadminium.ru]:

Обратите внимание, все параметры были использованы из конфига, вручную мне не пришлось ничего вписывать.

Создаю сертификат для домена

Теперь, с помощью корневых ключей, подписываю файл запроса и создаю сертификат для домена:

$ openssl x509 -req -days 730 -CA rootCA.crt -CAkey rootCA.key -extfile sysadminium.cnf -extensions req_ext -in site.csr -out site.crt

Разберу команду:

• x509 — создание сертификата путём подписывания;
• -req — если подписывать будем файл запроса, то нужно использовать эту опцию;
• -days 730 — сертификат я делаю на 2 года;
• -CA rootCA.crt -CAkey rootCA.key — указываю корневую пару ключей;
• -extfile sysadminium.cnf — файл, содержащий расширения сертификатов. Без этой опции расширения из файла запроса не попадут в сертификат;
• -in site.csr -out site.crt — файл запроса и файл сертификата.

После проделанного у меня появились три файла связанных с сертификатом для домена:

$ ls -l site.*
-rw-r--r-- 1 alex alex 1257 сен  9 14:27 site.crt # сертификат
-rw-r--r-- 1 alex alex 1098 сен  9 14:17 site.csr # запрос
-rw------- 1 alex alex 1704 сен  9 14:15 site.key # ключ

Перенастраиваю apache2

Кинем сертификат и ключ в следующие каталоги:

$ sudo cp site.crt /etc/ssl/certs/
$ sudo cp site.key /etc/ssl/private/

И настроим apache2 на использование этих ключей:

$ sudo nano /etc/apache2/sites-enabled/default-ssl.conf
   SSLCertificateFile      /etc/ssl/certs/site.crt
   SSLCertificateKeyFile /etc/ssl/private/site.key

Применим изменение конфига apache2:

$ sudo systemctl reload apache2

И проверим как открывается наш сайт с клиента на котором установлен наш корневой сертификат:

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

Смотрим на сертификат из Chrome

Нажмите на замочек возле адреса сайта (он виден на скриншоте выше). Дальше нажмите на «Безопасное подключение» и на «Действительный сертификат«. Откроются свойства сертификата:

На вкладке «Подробнее» вы можете изучить и остальные свойства.

Например, помните мы указывали алгоритм ассиметричного шифрования — RSA:

А помните, мы создали файл для серийных номеров выпускаемых сертификатов и записали в нём «00». Давайте посмотрим на серийный номер нашего сертификата:

Можем посмотреть на сам открытый ключ:

А в расширениях видно альтернативное имя, которое так нужно браузеру Chrome для доверия к сертификату:

Раньше браузеры проверяли только CN:

А сейчас, если есть альтернативное имя, то они даже не смотрят в параметр Common Name. А Chrome требует это поле и вообще перестал смотреть на Common Name.

Настраиваю веб-сервер Nginx

Ну и наконец я покажу как настроить Nginx на использование наших сертификатов.

Для начала выключу apache2 и установлю nginx:

$ sudo systemctl stop apache2.service
$ sudo apt install nginx

И настрою его. Нужно рас-комментировать и поменять значения некоторых полей:

$ sudo nano /etc/nginx/sites-enabled/default
   listen 443 ssl default_server;
   listen [::]:443 ssl default_server;
   ssl_certificate     /etc/ssl/certs/site.crt;
   ssl_certificate_key /etc/ssl/private/site.key;

Применю изменения:

$ sudo systemctl reload nginx

И наконец, проверю доверие к ssl-сертификату сайта, обновив страничку в браузере.

Здесь apache2 создал свою индексную страничку, поэтому оба веб сервера (nginx и apache2) используют одну и туже страницу. Но как вы помните, я отключил apache2, так что у меня точно отвечает nginx.

Итог

Надеюсь я смог объяснить, как сделать свой центр сертификации и начать выпускать свои собственные сертификаты для доменов. Мы создали следующие файлы:

• rootCA.key — корневой закрытый ключ. Используется для создания дочерних сертификатов. Обычно лежит на сервере центра сертификации и зашифрован с помощью пароля.
• rootCA.srl — корневой сертификат. Используется для создания дочерних сертификатов. Его нужно распространить на все ваши компьютеры и установить в хранилище корневых сертификатов. Его тоже можно защитить паролем, но я этого не делал.
• site.key — ключ для домена (для веб сервера). Его можно было сгенерировать на веб-сервере и не передавать на сервер центра сертификации. Но в моём примере был один сервер и для веб-сервера и для центра сертификации.
• site.csr — файл запроса на сертификат для домена. Его также можно было сделать на веб-сервере и передать в центр сертификации, чтобы там выпустить сертификат.
• site.crt — сертификат для домена (для веб сервера). Этот файл создаётся из файла запроса на сертификат с помощью пары корневых ключей.

Также я показал, как использовать созданные сертификаты для настройки веб серверов: apache2 и nginx.

Если вы интересуетесь настройками веб-серверов на Linux, то возможно вам также понравится эта статья:

• Nginx. Reverse Proxy