Сертификатов сервер: Обзор развертывания сертификата сервера | Microsoft Docs

Обзор развертывания сертификата сервера | Microsoft Docs

• 
  08.08.2020
• Чтение занимает 5 мин

В этой статье

Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

В этом разделе содержатся следующие подразделы.This topic contains the following sections.

Компоненты развертывания сертификата сервераServer certificate deployment components

Это руководством можно использовать для установки служб сертификатов Active Directory (AD CS) в качестве корневого центра сертификации (ЦС) предприятия, а также для регистрации сертификатов серверов на серверах, на которых выполняется сервер политики сети (NPS), служба маршрутизации и удаленного доступа (RRAS) или как NPS, так и RRAS.You can use this guide to install Active Directory Certificate Services (AD CS) as an Enterprise root certification authority (CA) and to enroll server certificates to servers that are running Network Policy Server (NPS), Routing and Remote Access service (RRAS), or both NPS and RRAS.

При развертывании SDN с проверкой подлинности на основе сертификата серверы должны использовать сертификат сервера, чтобы доказать свои удостоверения другим серверам, чтобы обеспечить безопасную связь.If you deploy SDN with certificate-based authentication, servers are required to use a server certificate to prove their identities to other servers so that they achieve secure communications.

На следующем рисунке показаны компоненты, необходимые для развертывания сертификатов сервера на серверах в инфраструктуре SDN.The following illustration shows the components that are required to deploy server certificates to servers in your SDN infrastructure.

Примечание

На рисунке выше показаны несколько серверов: DC1, CA1, WEB1 и многие серверы SDN.In the illustration above, multiple servers are depicted: DC1, CA1, WEB1, and many SDN servers. В этом учебнике содержатся инструкции по развертыванию и настройке CA1 и WEB1, а также для настройки DC1, в которой предполагается, что в вашей сети уже установлено приложение.This guide provides instructions for deploying and configuring CA1 and WEB1, and for configuring DC1, which this guide assumes you have already installed on your network. Если вы еще не установили домен Active Directory, это можно сделать с помощью основного сетевого каталога для Windows Server 2016.If you have not already installed your Active Directory domain, you can do so by using the Core Network Guide for Windows Server 2016.

Дополнительные сведения о каждом элементе, показанном на рисунке выше, см. в следующих статьях:For more information on each item depicted in the illustration above, see the following:

CA1, выполняющий роль сервера AD CSCA1 running the AD CS server role

В этом сценарии корневой центр сертификации (ЦС) предприятия также выдает выдающий ЦС.In this scenario, the Enterprise Root certification authority (CA) is also an issuing CA. ЦС выдает сертификаты на серверные компьютеры, имеющие правильные разрешения безопасности для регистрации сертификата.The CA issues certificates to server computers that have the correct security permissions to enroll a certificate. Службы сертификатов Active Directory (AD CS) установлены в CA1.Active Directory Certificate Services (AD CS) is installed on CA1.

Для более крупных сетей или в случаях, когда вопросы безопасности обеспечивают обоснование, можно разделить роли корневого центра сертификации и выдачу ЦС, а также развернуть подчиненные ЦС, выдающие ЦС.For larger networks or where security concerns provide justification, you can separate the roles of root CA and issuing CA, and deploy subordinate CAs that are issuing CAs.

В наиболее безопасных развертываниях корневой ЦС предприятия переключается в автономный режим и физически защищаются.In the most secure deployments, the Enterprise Root CA is taken offline and physically secured.

Файл CAPolicy. INFCAPolicy.inf

Перед установкой служб AD CS необходимо настроить файл CAPolicy. INF с конкретными параметрами развертывания.Before you install AD CS, you configure the CAPolicy.inf file with specific settings for your deployment.

Копия шаблона сертификата серверов RAS и IASCopy of the RAS and IAS servers certificate template

При развертывании сертификатов сервера необходимо создать одну копию шаблона сертификата серверов RAS и IAS , а затем настроить шаблон в соответствии с вашими требованиями и инструкциями в этом разделе.When you deploy server certificates, you make one copy of the RAS and IAS servers certificate template and then configure the template according to your requirements and the instructions in this guide.

Вы используете копию шаблона, а не исходный шаблон, чтобы конфигурация исходного шаблона сохранилась для использования в будущем.You utilize a copy of the template rather than the original template so that the configuration of the original template is preserved for possible future use. Вы настраиваете копию шаблона RAS-и IAS-серверов , чтобы центр сертификации мог создавать сертификаты серверов, которые он выдает группам, в Active Directory пользователи и компьютеры, которые вы указали.You configure the copy of the RAS and IAS servers template so that the CA can create server certificates that it issues to the groups in Active Directory Users and Computers that you specify.

Дополнительная конфигурация CA1Additional CA1 configuration

ЦС публикует список отзыва сертификатов (CRL), который должен проверить компьютеры, чтобы убедиться, что сертификаты, представленные им в качестве подтверждения личности, являются действительными сертификатами и не были отозваны.The CA publishes a certificate revocation list (CRL) that computers must check to ensure that certificates that are presented to them as proof of identity are valid certificates and have not been revoked. Необходимо настроить центр сертификации, указав правильное расположение списка отзыва сертификатов, чтобы компьютеры могли узнать, где искать список отзыва сертификатов в процессе проверки подлинности.You must configure your CA with the correct location of the CRL so that computers know where to look for the CRL during the authentication process.

WEB1, выполняющий роль сервера веб-служб (IIS)WEB1 running the Web Services (IIS) server role

На компьютере, на котором работает серверная роль веб-сервера (IIS), WEB1, необходимо создать папку в проводнике Windows для использования в качестве расположения для списка отзыва сертификатов и AIA.On the computer that is running the Web Server (IIS) server role, WEB1, you must create a folder in Windows Explorer for use as the location for the CRL and AIA.

Виртуальный каталог для списков отзыва сертификатов и AIAVirtual directory for the CRL and AIA

После создания папки в проводнике Windows необходимо настроить ее в качестве виртуального каталога в диспетчере службы IIS (IIS), а также для настройки списка управления доступом для виртуального каталога, чтобы разрешить компьютерам доступ к AIA и списку отзыва сертификатов после их публикации.After you create a folder in Windows Explorer, you must configure the folder as a virtual directory in Internet Information Services (IIS) Manager, as well as configuring the access control list for the virtual directory to allow computers to access the AIA and CRL after they are published there.

DC1 с ролью AD DS и DNS-сервераDC1 running the AD DS and DNS server roles

DC1 — это контроллер домена и DNS-сервер в сети.DC1 is the domain controller and DNS server on your network.

групповая политика политики домена по умолчаниюGroup Policy default domain policy

После настройки шаблона сертификата в центре сертификации можно настроить политику домена по умолчанию в групповая политика, чтобы сертификаты автоматически подписываются на серверы NPS и RAS.After you configure the certificate template on the CA, you can configure the default domain policy in Group Policy so that certificates are autoenrolled to NPS and RAS servers. Групповая политика настраивается в AD DS на сервере DC1.Group Policy is configured in AD DS on the server DC1.

Запись ресурса псевдонима DNS (CNAME)DNS alias (CNAME) resource record

Необходимо создать запись ресурса псевдонима (CNAME) для веб-сервера, чтобы убедиться, что другие компьютеры могут найти сервер, а также AIA и список отзыва сертификатов, которые хранятся на сервере.You must create an alias (CNAME) resource record for the Web server to ensure that other computers can find the server, as well as the AIA and the CRL that are stored on the server. Кроме того, использование записи ресурса псевдонима CNAME обеспечивает гибкость, чтобы можно было использовать веб-сервер для других целей, например для размещения веб-узлов и сайтов FTP.In addition, using an alias CNAME resource record provides flexibility so that you can use the Web server for other purposes, such as hosting Web and FTP sites.

NPS1, выполняющий службу роли сервера политики сети для роли сервера «политика сети и службы доступа»NPS1 running the Network Policy Server role service of the Network Policy and Access Services server role

Сервер политики сети устанавливается при выполнении задач в сетевом каталоге Windows Server 2016 Core, поэтому перед выполнением задач в этом разделе необходимо, чтобы в сети уже было установлено одно или несколько НПСС.The NPS is installed when you perform the tasks in the Windows Server 2016 Core Network Guide, so before you perform the tasks in this guide, you should already have one or more NPSs installed on your network.

групповая политика применены и сертификат зарегистрирован на серверахGroup Policy applied and certificate enrolled to servers

После настройки шаблона сертификата и автоматической регистрации можно обновить групповая политика на всех целевых серверах.After you have configured the certificate template and autoenrollment, you can refresh Group Policy on all target servers. В настоящее время серверы регистрируют сертификат сервера из CA1.At this time, the servers enroll the server certificate from CA1.

Обзор процесса развертывания сертификата сервераServer certificate deployment process overview

Процесс настройки регистрации сертификата сервера выполняется на следующих этапах:The process of configuring server certificate enrollment occurs in these stages:

1. В WEB1 установите роль веб-сервера (IIS).On WEB1, install the Web Server (IIS) role.

2. На компьютере DC1 создайте запись псевдонима (CNAME) для веб-сервера WEB1.On DC1, create an alias (CNAME) record for your Web server, WEB1.

3. Настройте веб-сервер для размещения списка отзыва сертификатов из центра сертификации, затем опубликуйте список отзыва сертификатов и скопируйте сертификат корневого ЦС предприятия в новый виртуальный каталог.Configure your Web server to host the CRL from the CA, then publish the CRL and copy the Enterprise Root CA certificate into the new virtual directory.

4. На компьютере, где планируется установить AD CS, назначьте компьютеру статический IP-адрес, переименуйте компьютер, Присоедините компьютер к домену, а затем войдите в систему, используя учетную запись пользователя, который является членом групп «Администраторы домена» и «Администраторы предприятия».On the computer where you are planning to install AD CS, assign the computer a static IP address, rename the computer, join the computer to the domain, and then log on to the computer with a user account that is a member of the Domain Admins and Enterprise Admins groups.

5. На компьютере, где планируется установить AD CS, настройте в файле CAPolicy. INF параметры, характерные для вашего развертывания.On the computer where you are planning to install AD CS, configure the CAPolicy.inf file with settings that are specific to your deployment.

6. Установите роль сервера AD CS и выполните дополнительную настройку ЦС.Install the AD CS server role and perform additional configuration of the CA.

7. Скопируйте список CRL и сертификат ЦС из CA1 в общую папку на веб-сервере WEB1.Copy the CRL and CA certificate from CA1 to the share on the Web server WEB1.

8. В центре сертификации Настройте копию шаблона сертификата Серверы RAS и IAS.On the CA, configure a copy of the RAS and IAS Servers certificate template. ЦС выдает сертификаты на основе шаблона сертификата, поэтому необходимо настроить шаблон для сертификата сервера, прежде чем ЦС сможет выдать сертификат.The CA issues certificates based on a certificate template, so you must configure the template for the server certificate before the CA can issue a certificate.

9. Настройте автоматическую регистрацию сертификата сервера в групповая политика.Configure server certificate autoenrollment in Group Policy. При настройке автоматической регистрации все серверы, указанные в Active Directory членства в группах, автоматически получают сертификат сервера при обновлении групповая политика на каждом сервере.When you configure autoenrollment, all servers that you have specified with Active Directory group memberships automatically receive a server certificate when Group Policy on each server is refreshed. Если позднее добавить серверы, они также будут автоматически получить сертификат сервера.If you add more servers later, they will automatically receive a server certificate, too.

10. Обновите групповая политика на серверах.Refresh Group Policy on servers. При обновлении групповая политика серверы получают сертификат сервера, основанный на шаблоне, настроенном на предыдущем шаге.When Group Policy is refreshed, the servers receive the server certificate, which is based on the template that you configured in the previous step. Этот сертификат используется сервером для подтверждения его подлинности клиентским компьютерам и другим серверам в процессе аутентификации.This certificate is used by the server to prove its identity to client computers and other servers during the authentication process.

    Примечание

    Все компьютеры, входящие в домен, автоматически получают сертификат корневого ЦС предприятия без настройки автоматической регистрации.All domain member computers automatically receive the Enterprise Root CA’s certificate without the configuration of autoenrollment. Этот сертификат отличается от сертификата сервера, настроенного и распространяемого с помощью автоматической регистрации.This certificate is different than the server certificate that you configure and distribute by using autoenrollment. Сертификат ЦС автоматически устанавливается в хранилище сертификатов доверенных корневых центров сертификации для всех компьютеров-членов домена, чтобы они доверяли сертификатам, выданным этим ЦС.The CA’s certificate is automatically installed in the Trusted Root Certification Authorities certificate store for all domain member computers so that they will trust certificates that are issued by this CA.

11. Убедитесь, что все серверы зарегистрировали действительный сертификат сервера.Verify that all servers have enrolled a valid server certificate.

Настройка автоматической регистрации сертификата сервера

• 
  08.08.2020
• Чтение занимает 2 мин

В этой статье

Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Примечание

Перед выполнением этой процедуры необходимо настроить шаблон сертификата сервера с помощью оснастки «Шаблоны сертификатов» консоли управления (MMC) в центре сертификации, где выполняется AD CS.Before you perform this procedure, you must configure a server certificate template by using the Certificate Templates Microsoft Management Console snap-in on a CA that is running AD CS.
Членство в группах «Администраторы предприятия » и «Администраторы домена корневого домена» является минимальным требованием для выполнения этой процедуры.Membership in both the Enterprise Admins and the root domain’s Domain Admins group is the minimum required to complete this procedure.

Настройка автоматической регистрации сертификата сервераConfigure server certificate auto-enrollment

1. На компьютере, где установлен AD DS, откройте Windows PowerShell ® , введите MMCи нажмите клавишу ВВОД.On the computer where AD DS is installed, open Windows PowerShell®, type mmc, and then press ENTER. Откроется консоль управления (MMC).The Microsoft Management Console opens.

2. В меню Файл выберите Добавить или удалить оснастку.On the File menu, click Add/Remove Snap-in. Откроется диалоговое окно Добавление или удаление оснасток .The Add or Remove Snap-ins dialog box opens.

3. В окне Доступные оснасткипрокрутите вниз до и дважды щелкните редактор «Управление групповыми политиками».In Available snap-ins, scroll down to and double-click Group Policy Management Editor. Откроется диалоговое окно Выбор объекта Групповая политика .The Select Group Policy Object dialog box opens.

   Важно!

   Убедитесь, что выбраны редактор «Управление групповыми политиками» и не Групповая политика управления.Ensure that you select Group Policy Management Editor and not Group Policy Management. Если выбрать Групповая политика управления, конфигурация с использованием этих инструкций завершится ошибкой, а сертификат сервера не будет автоматически зарегистрирован в НПСС.If you select Group Policy Management, your configuration using these instructions will fail and a server certificate will not be autoenrolled to your NPSs.

4. В Групповая политика объектнажмите кнопку Обзор.In Group Policy Object, click Browse. Откроется диалоговое окно » Поиск объекта Групповая политика «.The Browse for a Group Policy Object dialog box opens.

5. В области домены, подразделения и связанные групповая политика объекты выберите Политика домена по умолчанию, а затем нажмите кнопку ОК.In Domains, OUs, and linked Group Policy Objects, click Default Domain Policy, and then click OK.

6. Нажмите кнопку Готово, а затем — кнопку ОК.Click Finish, and then click OK.

7. Дважды щелкните Политика домена по умолчанию.Double-click Default Domain Policy. В консоли разверните следующий путь: Конфигурация компьютера, политики, Параметры Windows, Параметры безопасностии политики открытого ключа.In the console, expand the following path: Computer Configuration, Policies, Windows Settings, Security Settings, and then Public Key Policies.

8. Щелкните политики открытого ключа.Click Public Key Policies. На панели подробностей дважды щелкните параметр Клиент службы сертификации: автоматическая регистрация.In the details pane, double-click Certificate Services Client — Auto-Enrollment. Откроется диалоговое окно Свойства .The Properties dialog box opens. Настройте следующие элементы и нажмите кнопку ОК.Configure the following items, and then click OK:

   1. В окне Модель конфигурации выберите параметр Включено.In Configuration Model, select Enabled.
   2. Установите флажок обновлять сертификаты с истекшим сроком действия, обновить отложенные сертификаты и удалить отозванные сертификаты .Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.
   3. Установите флажок Обновлять сертификаты, использующие шаблоны сертификатов.Select the Update certificates that use certificate templates check box.

9. Нажмите кнопку ОК.Click OK.

Настройка автоматической регистрации сертификата пользователяConfigure user certificate auto-enrollment

1. На компьютере, где установлен AD DS, откройте Windows PowerShell ® , введите MMCи нажмите клавишу ВВОД.On the computer where AD DS is installed, open Windows PowerShell®, type mmc, and then press ENTER. Откроется консоль управления (MMC).The Microsoft Management Console opens.

2. В меню Файл выберите Добавить или удалить оснастку.On the File menu, click Add/Remove Snap-in. Откроется диалоговое окно Добавление или удаление оснасток .The Add or Remove Snap-ins dialog box opens.

3. В окне Доступные оснасткипрокрутите вниз до и дважды щелкните редактор «Управление групповыми политиками».In Available snap-ins, scroll down to and double-click Group Policy Management Editor. Откроется диалоговое окно Выбор объекта Групповая политика .The Select Group Policy Object dialog box opens.

   Важно!

   Убедитесь, что выбраны редактор «Управление групповыми политиками» и не Групповая политика управления.Ensure that you select Group Policy Management Editor and not Group Policy Management. Если выбрать Групповая политика управления, конфигурация с использованием этих инструкций завершится ошибкой, а сертификат сервера не будет автоматически зарегистрирован в НПСС.If you select Group Policy Management, your configuration using these instructions will fail and a server certificate will not be autoenrolled to your NPSs.

4. В Групповая политика объектнажмите кнопку Обзор.In Group Policy Object, click Browse. Откроется диалоговое окно » Поиск объекта Групповая политика «.The Browse for a Group Policy Object dialog box opens.

5. В области домены, подразделения и связанные групповая политика объекты выберите Политика домена по умолчанию, а затем нажмите кнопку ОК.In Domains, OUs, and linked Group Policy Objects, click Default Domain Policy, and then click OK.

6. Нажмите кнопку Готово, а затем — кнопку ОК.Click Finish, and then click OK.

7. Дважды щелкните Политика домена по умолчанию.Double-click Default Domain Policy. В консоли разверните следующий путь: Конфигурация пользователя, политики, Параметры Windows, Параметры безопасности.In the console, expand the following path: User Configuration, Policies, Windows Settings, Security Settings.

8. Щелкните политики открытого ключа.Click Public Key Policies. На панели подробностей дважды щелкните параметр Клиент службы сертификации: автоматическая регистрация.In the details pane, double-click Certificate Services Client — Auto-Enrollment. Откроется диалоговое окно Свойства .The Properties dialog box opens. Настройте следующие элементы и нажмите кнопку ОК.Configure the following items, and then click OK:

   1. В окне Модель конфигурации выберите параметр Включено.In Configuration Model, select Enabled.
   2. Установите флажок обновлять сертификаты с истекшим сроком действия, обновить отложенные сертификаты и удалить отозванные сертификаты .Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.
   3. Установите флажок Обновлять сертификаты, использующие шаблоны сертификатов.Select the Update certificates that use certificate templates check box.

9. Нажмите кнопку ОК.Click OK.

Next StepsNext Steps

Обновить групповая политикаRefresh Group Policy

🗝️ Как создать CA и генерировать сертификаты и ключи SSL / TLS — Information Security Squad

В этом руководстве объясняется процесс создания ключей и сертификатов CA и их использования для создания сертификатов и ключей SSL / TLS с использованием таких утилит SSL, как openssl и cfssl.

Терминологии, используемые в этой статье:

1. PKI – Public key infrastructure
2. CA – Certificate Authority
3. CSR – Certificate signing request
4. SSL – Secure Socket Layer
5. TLS – Transport Layer Security

Рабочий процесс создания сертификата

Ниже приведены шаги, необходимые для создания сертификатов CA, SSL / TLS.

CA ключ и создание сертификата

• Создайте файл закрытого ключа CA с помощью утилиты (OpenSSL, cfssl и т. д.)
• Создайте корневой сертификат CA, используя закрытый ключ CA.

Процесс создания сертификата сервера

• Сгенерируйте закрытый ключ сервера с помощью утилиты (OpenSSL, cfssl и т. д.)
• Создайте CSR, используя закрытый ключ сервера.
• Создайте сертификат сервера, используя ключ CA, сертификат CA и CSR сервера.

В этом руководстве мы объясним шаги, необходимые для создания сертификатов CA, SSL / TLS с использованием следующих утилит:

1. openssl
2. cfssl

Данное руководство посвящено созданию собственных сертификатов CA, SSL / TLS.

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

Для использования в общедоступных (интернет) службах, вы должны рассмотреть возможность использования любых доступных сторонних служб CA, таких как Digicert и т. д.

Генерация сертификатов с использованием CFSSL и CFSSLJSON

CFSSL и CFSSLJSON являются инструментами PKI от Cloudflare. Это делает вашу жизнь проще для создания CSR и ключей сертификатов.

Установите CFSSL и CFSSLJSON на Linux

1. Загрузите исполняемые файлы и сохраните их в /usr/local/bin

curl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
       -o /usr/local/bin/cfssl
curl https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 \
       -o /usr/local/bin/cfssljson
curl https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 \
       -o /usr/local/bin/cfssl-certinfo

2. Добавьте права на выполнение для загруженных исполняемых файлов.

3. Проверьте установку, выполнив команду cfssl:

Создайте сертификат CA и его ключ

Шаг 1: Создайте папку с именем cfssl для хранения всех сертификатов и перейдите в папку.

mkdir cfssl
cd cfssl

Шаг 2: Создайте файл ca-csr.json с необходимой информацией.

cat > ca-csr.json <<EOF
{
"CN": "Demo CA",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "US",
"L": "California",
"ST": "Milpitas"
}
]
}
EOF

Вы можете проверить поддерживаемые значения для csr и config, используя следующие команды:

cfssl print-defaults config
cfssl print-defaults csr

Шаг 2. Создайте ключ CA и файл сертификата (ca-key.pem и ca.pem) с помощью файла ca-csr.json.

cfssl gencert -initca ca-csr.json | cfssljson -bare ca –

Шаг 3: Создайте ca-config.json с подписью и данными профиля.

Это будет использоваться для создания сертификатов сервера или клиента, которые можно использовать для настройки аутентификации на основе SSL / TSL.

cat > ca-config.json <<EOF 
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"web-servers": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
EOF

Генерация сертификатов SSL / TLS

Шаг 1: Создайте server-csr.json с данными вашего сервера.

Примечание: запись hosts в json должна содержать DNS или публичный / частный IP-адрес сервера, имена хостов, локальный DNS и т. д. В зависимости от интерфейса, гп который вы хотите получать запросы на аутентификацию. Например, у вас может быть сервер с аутентификацией TLS через общедоступные сети и частная сеть внутри организации.

Шаг 2: Теперь создайте SSL-сертификаты сервера, используя ключи CA, certs и csr сервера.

Это создаст файлы server-key.pem (закрытый ключ) и server.pem (сертификаты).

 cfssl gencert \
-ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-profile=web-servers \
server-csr.json | cfssljson -bare server

Генерация сертификатов с использованием OpenSSL

Утилита Openssl присутствует по умолчанию во всех системах на базе Linux и Unix.

Создайте сертификат CA и его ключ

Шаг 1: Создайте каталог openssl и CD к нему.

mkdir openssl && cd openssl

Шаг 2: Сгенерируйте файл секретного ключа CA.

openssl genrsa -out ca.key 2048

Шаг 3: Сгенерируйте файл сертификата CA x509, используя ключ CA.

Вы можете определить срок действия сертификата в днях.

Здесь мы указали 1825 дней.

Следующая команда запросит детали сертификата, такие как имя команды, местоположение, страна и т. д.

openssl req -x509 -new -nodes \
     -key ca.key -sha256 \
     -days 1825 -out ca.crt

Или вы можете передать эту информацию в команду, как показано ниже.

Генерация сертификатов SSL / TLS

Шаг 1. Создайте закрытый ключ сервера

openssl genrsa -out server.key 2048

Шаг 2. Создайте файл конфигурации с именем csr.conf для генерации запроса на подпись сертификата (CSR), как показано ниже.

Замените значения в соответствии с вашими потребностями.

cat > csr.conf <<EOF

[ req ]

default_bits = 2048

prompt = no

default_md = sha256

req_extensions = req_ext

distinguished_name = dn

[ dn ]

C = US

ST = California

L = San Fransisco

O = Scriptcrunch

OU = Scriptcrunch Dev

CN = scriptcrunch.com

[ req_ext ]

subjectAltName = @alt_names

[ alt_names ]

DNS.1 = scriptcrunch

DNS.2 = scriptcrunch.com

IP.1 = 10.34.12.5

IP.2 = 10.34.12.5

[ v3_ext ]

authorityKeyIdentifier=keyid,issuer:always

basicConstraints=CA:FALSE

keyUsage=keyEncipherment,dataEncipherment

extendedKeyUsage=serverAuth,clientAuth

subjectAltName=@alt_names

EOF

alt_names должен содержать DNS ваших серверов, где вы хотите использовать SSL.
Также добавьте все IP-адреса, связанные с сервером, если клиенты используют этот IP-адрес для подключения к серверу по протоколу SSL.

Шаг 3: Сгенерируйте CSR, используя закрытый ключ и файл конфигурации.

openssl req -new -key server.key -out server.csr -config csr.conf

Шаг 4. Создайте SSL-сертификат сервера, используя ca.key, ca.crt и server.csr

Настройка шаблона сертификата сервера | Microsoft Docs

• 
  08.08.2020
• Чтение занимает 2 мин

В этой статье

Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Эту процедуру можно использовать для настройки шаблона сертификата, который Active Directory ® служб сертификации (AD CS) используется в качестве основания для сертификатов сервера, зарегистрированных на серверах в сети.You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for server certificates that are enrolled to servers on your network.

При настройке этого шаблона можно указать серверы по Active Directory группе, которые должны автоматически получить сертификат сервера из AD CS.While configuring this template, you can specify the servers by Active Directory group that should automatically receive a server certificate from AD CS.

Приведенная ниже процедура содержит инструкции по настройке шаблона для выдаче сертификатов для всех следующих типов серверов:The procedure below includes instructions for configuring the template to issue certificates to all of the following server types:

• Серверы, на которых выполняется служба удаленного доступа, включая серверы шлюзов RAS, входящие в группу Серверы RAS и IAS .Servers that are running the Remote Access service, including RAS Gateway servers, that are members of the RAS and IAS Servers group.
• Серверы, на которых выполняется служба сервера политики сети (NPS), входящие в группу серверов RAS и IAS .Servers that are running the Network Policy Server (NPS) service that are members of the RAS and IAS Servers group.

Членство в группах «Администраторы предприятия » и «Администраторы домена корневого домена» является минимальным требованием для выполнения этой процедуры.Membership in both the Enterprise Admins and the root domain’s Domain Admins group is the minimum required to complete this procedure.

Настройка шаблона сертификатаTo configure the certificate template

1. В CA1 в диспетчер сервера выберите Сервис, а затем щелкните центр сертификации.On CA1, in Server Manager, click Tools, and then click Certification Authority. Откроется консоль управления (MMC) центра сертификации.The Certification Authority Microsoft Management Console (MMC) opens.

2. В консоли управления (MMC) дважды щелкните имя ЦС, щелкните правой кнопкой мыши шаблоны сертификатов, а затем выберите пункт Управление.In the MMC, double-click the CA name, right-click Certificate Templates, and then click Manage.

3. Откроется консоль Шаблоны сертификатов.The Certificate Templates console opens. Все шаблоны сертификатов отображаются в области сведений.All of the certificate templates are displayed in the details pane.

4. В области сведений выберите шаблон сервер RAS и IAS .In the details pane, click the RAS and IAS Server template.

5. В меню действие выберите пункт дублировать шаблон.Click the Action menu, and then click Duplicate Template. Откроется диалоговое окно Свойства шаблона.The template Properties dialog box opens.

6. Перейдите на вкладку Безопасность .Click the Security tab.

7. На вкладке Безопасность в поле имена групп или пользователейщелкните Серверы RAS и IAS.On the Security tab, in Group or user names, click RAS and IAS servers.

8. В области разрешения для серверов RAS и IASв разделе Разрешитьубедитесь, что выбран параметр Регистрация , а затем установите флажок Автоматическая регистрация .In Permissions for RAS and IAS servers, under Allow, ensure that Enroll is selected, and then select the Autoenroll check box. Нажмите кнопку ОКи закройте оснастку MMC «Шаблоны сертификатов».Click OK, and close the Certificate Templates MMC.

9. В консоли MMC центр сертификации щелкните шаблоны сертификатов.In the Certification Authority MMC, click Certificate Templates. В меню действие наведите указатель на пункт создатьи выберите пункт Выдаваемый шаблон сертификата.On the Action menu, point to New, and then click Certificate Template to Issue. Откроется диалоговое окно Включение шаблонов сертификатов .The Enable Certificate Templates dialog box opens.

10. В окне Включение шаблонов сертификатовщелкните имя только что настроенного шаблона сертификата и нажмите кнопку ОК.In Enable Certificate Templates, click the name of the certificate template that you just configured, and then click OK. Например, если вы не изменили имя шаблона сертификата по умолчанию, щелкните Копия RAS-сервера и IAS-сервер, а затем нажмите кнопку ОК.For example, if you did not change the default certificate template name, click Copy of RAS and IAS Server, and then click OK.

Установка центра сертификации на предприятии. Часть 1 / Блог компании Microsoft / Хабр

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Вторая часть серии

Третья часть серии

Введение

Целевая аудитория

ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа (ИОК), набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба, выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология, обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, являющийся частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.

Зачем нужен частный PKI?

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).

Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.

Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.

Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.

Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:

Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.

 

Общие положения

PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:

• Шифрование – защищает данные от несанкционированного доступа третьих лиц путём шифрования данных криптографическими ключами. Только пользователи, имеющие необходимые ключи, могут получить доступ к данным. Шифрование обеспечивает секретность данных, но не защищает от их подмены.
• Цифровая подпись – защищает данные от несанкционированного изменения или подделки путём применения к данным специальных алгоритмов, которые образуют цифровую подпись. Любые манипуляции по изменению данных будут немедленно обнаружены при проверке цифровой подписи. Цифровая подпись обеспечивает не конфиденциальность данных, а их целостность. Путём комбинирования шифрования и цифровой подписи можно организовать обеспечение конфиденциальности и защиты данных от несанкционированных изменений.

Типичная инфраструктура PKI состоит из следующих компонентов:

• Центр Сертификации (ЦС) – служба, предоставляющая цифровые сертификаты потребителям и обеспечивающая функционирование PKI.
• Сервер отзыва – служба, предоставляющая информацию о списках отозванных (скомпрометированных или недействительных) сертификатов, выпущенных конкретным ЦС.
• Клиент – получатель заверенного цифрового сертификата от центра сертификации. Клиентами могут выступать люди, устройства, программное обеспечение, а также другие ЦС.

Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:

• Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева. Важно отметить, что доверие транзитивно. Клиент при проверке конечного сертификата будет выстраивать цепочку (путь) от конечного сертификата до вершины иерархии (корневого сертификата). И если клиент доверяет вершине, то будут и основания доверять конечному сертификату на правах транзитивности.
• ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.
• Издающий ЦС – это ЦС общего назначения, который выполняет подпись и выдачу цифровых сертификатов потребителям.

Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine — how it works. Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.

Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.

Отзыв сертификатов

Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.

Каждый клиент после установки доверия сертификата через цепочку должен убедиться, что ни один сертификат в цепочке не был отозван своим издателем. Для этого клиент перебирает каждый сертификат в цепочке, выбирает CRL предоставленный издателем и проверяет наличие/отсутствие текущего сертификата в списке CRL. Если текущий сертификат находится в CRL, то доверие к сертификату (и всем ветвям дерева под ним) автоматически обрывается.

Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.

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

Типовые схемы развёртывания иерархии PKI

В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.

Одноуровневая иерархия

Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:

Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.

Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.

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

Недостатки одноуровневой иерархии заметно перевешивают её преимущества в лёгкости и компактности. Именно поэтому такая конфигурация имеет смысл лишь в каких-то небольших и изолированных сетях с низкими требованиями по безопасности. Например, это может быть какая-то тестовая среда. В бизнес-среде такое решение использовать не рекомендуется.

Двухуровневая иерархия

Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:

Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.

В двухуровневой иерархии уже возможно решить недостатки одноуровневой иерархии. Здесь корневой ЦС выпускает сертификаты только для подчинённых ЦС, а уже подчинённый ЦС выдаёт сертификаты конечным потребителям. Поскольку издающие ЦС развёртываются не так часто, и срок их действия достаточного велик, это позволяет изолировать корневой ЦС от сети. Это автоматически сводит к нулю шанс компрометации такого ЦС, поскольку без сети к нему не добраться. Более того, основное время жизни он может (и должен) проводить в выключенном состоянии. Включать его нужно только для обновления собственного сертификата, подчинённого ЦС или для публикации нового CRL. В остальное время он никому не нужен.

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

Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи) и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.

Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.

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

Трёх- и более уровневые иерархии

В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе. Представьте международную компанию с региональными офисами в разных странах. В них может действовать своё законодательство в вопросах безопасности, например, при обработке персональных данных. Для соблюдения подобных юридических формальностей на каждый такой регион выделяется свой собственный ЦС политик (при этом, размещается он, как правило, в головном офисе компании). В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).

В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:

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

К плюсам такой схемы можно отнести гибкость полученной PKI с возможностью адаптации под практически любые условия. Правда, за это придётся платить. Во-первых, многоуровневые иерархии удорожают стоимость развёртывания и сопровождения PKI. Во-вторых, клиентам требуется больше времени на построение и проверки на отзыв полных цепочек сертификатов, что может вызывать отказы из-за превышения таймаутов верхних протоколов передачи данных. И на практике такие схемы зачастую являются избыточными. Поэтому при выборе подходящей иерархии ЦС следует искать баланс между гибкостью и практической целесообразностью с учётом капитальных и операционных затрат на содержание PKI.

В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

Требования к сертификатам для серверов федерации

• 
  05/31/2017
• Чтение занимает 4 мин

В этой статье

В любой службы федерации Active Directory (AD FS) ( AD FS ) необходимо использовать различные сертификаты для защиты обмена данными и упрощения проверки подлинности пользователей между Интернетом и серверами федерации.In any Active Directory Federation Services (AD FS) design, various certificates must be used to secure communication and facilitate user authentications between Internet clients and federation servers. Каждый сервер федерации должен иметь сертификат связи службы и сертификат подписи маркера, — прежде чем он сможет участвовать в AD FS связи.Each federation server must have a service communication certificate and a token-signing certificate before it can participate in AD FS communications. В следующей таблице описаны типы сертификатов, связанные с сервером федерации.The following table describes the certificate types that are associated with federation server.

Вы можете запросить и установить сертификат SSL или сертификат связи службы, запросив сертификат связи службы с помощью ( оснастки MMC консоли управления ) — для IIS.You can request and install an SSL certificate or service communication certificate by requesting a service communication certificate through the Microsoft Management Console (MMC) snap-in for IIS. Дополнительные общие сведения об использовании SSL-сертификатов см. в разделе iis 7,0: настройка SSL в iis 7,0 и IIS 7,0: Настройка сертификатов сервера в IIS 7,0 .For more general information about using SSL certificates, see IIS 7.0: Configuring Secure Sockets Layer in IIS 7.0 and IIS 7.0: Configuring Server Certificates in IIS 7.0 .

Примечание

В AD FS можно изменить уровень SHA для алгоритма безопасного хэширования ( ) , который используется для цифровых подписей: SHA — 1 или SHA — 256 ( ) .In AD FS you can change the Secure Hash Algorithm (SHA) level that is used for digital signatures to either SHA-1 or SHA-256 (more secure). AD Фсдоес не поддерживает использование сертификатов с другими методами хэширования, например MD5 — ( алгоритм хэширования по умолчанию, используемый в — средстве командной строки Makecert.exe ) .AD FSdoes not support the use of certificates with other hash methods, such as MD5 (the default hash algorithm that is used with the Makecert.exe command-line tool). По соображениям безопасности рекомендуется использовать SHA — 256, ( который по умолчанию задан ) для всех подписей.As a security best practice, we recommend that you use SHA-256 (which is set by default) for all signatures. SHA — 1 рекомендуется использовать только в сценариях, в которых необходимо взаимодействовать с продуктом, который не поддерживает обмен данными с помощью SHA — 256, например, не от — продукта Майкрософт или AD FS 1.SHA-1 is recommended for use only in scenarios in which you must interoperate with a product that does not support communications using SHA-256, such as a non-Microsoft product or AD FS 1. x.x.

Определение стратегии центра сертификацииDetermining your CA strategy

AD FS не требует, чтобы сертификаты выдавались центром сертификации.AD FS does not require that certificates be issued by a CA. Однако сертификат SSL, ( который также используется по умолчанию как сертификат связи служб, ) должен быть доверенным для клиентов AD FS.However, the SSL certificate (the certificate that is also used by default as the service communications certificate) must be trusted by the AD FS clients. -Для этих типов сертификатов не рекомендуется использовать самозаверяющие сертификаты.We recommend that you not use self-signed certificates for these certificate types.

Важно!

Использование самозаверяющих — сертификатов SSL в рабочей среде может позволить злонамеренному пользователю в организации партнера по учетным записям получить контроль над серверами федерации в организации партнера по ресурсам.Use of self-signed, SSL certificates in a production environment can allow a malicious user in an account partner organization to take control of federation servers in a resource partner organization. Такая угроза безопасности существует, поскольку самозаверяющие — сертификаты являются корневыми.This security risk exists because self-signed certificates are root certificates. Они должны быть добавлены в доверенное корневое хранилище другого сервера федерации, ( например, на сервере федерации ресурсов ) , который может оставить этот сервер уязвимым для атак.They must be added to the trusted root store of another federation server (for example, the resource federation server), which can leave that server vulnerable to attack.

После получения сертификата из центра сертификации необходимо убедиться, что все сертификаты импортированы в хранилище личных сертификатов на локальном компьютере.After you receive a certificate from a CA, make sure that all certificates are imported into the personal certificate store of the local computer. Сертификаты можно импортировать в личное хранилище с помощью оснастки MMC «сертификаты» — в.You can import certificates to the personal store with the Certificates MMC snap-in.

В качестве альтернативы использованию оснастки «сертификаты» — в можно также ИМПОРТИРОВАТЬ SSL-сертификат с помощью оснастки «Диспетчер IIS» — в момент назначения сертификата SSL веб сайту по умолчанию.As an alternative to using the Certificates snap-in, you can also import the SSL certificate with the IIS Manager snap-in at the time that you assign the SSL certificate to the default Web site. Дополнительные сведения см. в разделе Импорт сертификата проверки подлинности сервера на веб-сайт по умолчанию.For more information, see Import a Server Authentication Certificate to the Default Web Site.

Примечание

Перед установкой AD FS программного обеспечения на компьютер, который станет сервером федерации, убедитесь, что оба сертификата находятся в хранилище личных сертификатов локального компьютера и что сертификат SSL назначен веб-сайту по умолчанию.Before you install the AD FS software on the computer that will become the federation server, make sure that both certificates are in the Local Computer personal certificate store and that the SSL certificate is assigned to the Default Web Site. Дополнительные сведения о порядке задач, необходимых для настройки сервера федерации, см. в разделе Контрольный список: Настройка сервера федерации.For more information about the order of the tasks that are required to set up a federation server, see Checklist: Setting Up a Federation Server.

В зависимости от требований безопасности и бюджетных ограничений необходимо тщательно продумать, какие из сертификатов будут присваиваться публичным или корпоративным центром сертификации.Depending on your security and budget requirements, carefully consider which of your certificates will be obtained by a public CA or a corporate CA. На рисунке ниже показаны рекомендованные издатели (центры сертификации) определенных типов сертификатов.The following figure shows the recommended CA issuers for a given certificate type. Эта рекомендация отражает оптимальный — подход к безопасности и затратам.This recommendation reflects a best-practice approach regarding security and cost.

Списки отзыва сертификатовCertificate revocation lists

Если у какого-либо используемого сертификата есть списки отзыва сертификатов (CRL), сервер с настроенным сертификатом должен иметь возможность связаться с сервером, распространяющим CRL.If any certificate that you use has CRLs, the server with the configured certificate must be able to contact the server that distributes the CRLs.

См. также:See Also

Руководство по разработке служб федерации Active Directory в Windows Server 2012AD FS Design Guide in Windows Server 2012

Авторизация клиентов в nginx посредством SSL сертификатов / Хабр

Введение:

Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».
Не я первый с этим столкнулся и мир давно уже использует для таких вещей SSL.

Поскольку на моём сервере используется nginx, то был установлен модуль SSL

Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.

Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.

Внимание! В статье для примера используются самоподписанные сертификаты!

Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:

cd /path/to/nginx/config/
mkdir ssl && cd ssl

Шаг 1. Создание собственного самоподписанного доверенного сертификата.

Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.

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

openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected] -out ca.crt

Описание аргументов:

req Запрос на создание нового сертификата.

-new Создание запроса на сертификат (Certificate Signing Request – далее CSR).

-newkey rsa:1023 Автоматически будет создан новый закрытый RSA ключ длиной 1024 бита. Длину ключа можете настроить по своему усмотрению.

-nodes Не шифровать закрытый ключ.

-keyout ca.key Закрытый ключ сохранить в файл ca.key.

-x509 Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.

-days 500 Срок действия сертификата 500 дней. Размер периода действия можете настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом вы будете подписывать клиентские сертификаты.

-subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected]

Данные сертификата, пары параметр=значение, перечисляются через ‘/’. Символы в значении параметра могут быть «подсечены» с помощью обратного слэша «\», например «O=My\ Inc». Также можно взять значение аргумента в кавычки, например, -subj «/xx/xx/xx».

Шаг 2. Сертификат сервера

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

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

Подпишем сертификат нашей же собственной подписью

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата

openssl rsa -in server.key -out server.nopass.key

Конфиг nginx

listen *:443;
ssl on;
ssl_certificate /path/to/nginx/ssl/server.crt;
ssl_certificate_key /path/to/nginx/ssl/server.nopass.key;
ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;

keepalive_timeout 70;
fastcgi_param SSL_VERIFIED $ssl_client_verify;
fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_DN $ssl_client_s_dn;

теперь сервер готов принимать запросы на https.

в переменных к бекенду появились переменные с информацией о сертификате, в первую очередь SSL_VERIFIED (принимает значение SUCCESS).

Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:

400 Bad Request
No required SSL certificate was sent

Что ж, логично, в этом-то и вся соль!

Шаг 3. Создание клиентских сертификатов

3.1 Подготовка CA

Создадим конфиг

nano ca.config

со следующим содержимым:

[ ca ]
default_ca = CA_CLIENT # При подписи сертификатов # использовать секцию CA_CLIENT

[ CA_CLIENT ]
dir = ./db # Каталог для служебных файлов
certs = $dir/certs # Каталог для сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов

database = $dir/index.txt # Файл с базой данных подписанных сертификатов
serial = $dir/serial # Файл содержащий серийный номер сертификата (в шестнадцатеричном формате)
certificate = ./ca.crt # Файл сертификата CA
private_key = ./ca.key # Файл закрытого ключа CA

default_days = 365 # Срок действия подписываемого сертификата
default_crl_days = 7 # Срок действия CRL
default_md = md5 # Алгоритм подписи

policy = policy_anything # Название секции с описанием политики в отношении данных сертификата

[ policy_anything ]
countryName = optional # Поля optional - не обязательны, supplied - обязательны
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле

mkdir db
mkdir db/certs
mkdir db/newcerts
touch db/index.txt
echo "01" > db/serial

3.2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)

Для создания подписанного клиентского сертификата предварительно необходимо создать запрос на сертификат, для его последующей подписи. Аргументы команды полностью аналогичны аргументам использовавшимся при создании самоподписанного доверенного сертификата, но отсутствует параметр -x509.

openssl req -new -newkey rsa:1024 -nodes -keyout client01.key -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected] -out client01.csr

В результате выполнения команды появятся два файла client01.key и client01.csr.

3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

openssl ca -config ca.config -in client01.csr -out client01.crt -batch

В результате выполнения команды появится файл клиентского сертификата client01.crt.

Для создания следующих сертификатов нужно повторять эти два шага.

3.4. Создание сертификата в формате PKCS#12 для браузера клиента

Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.
Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.

openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e3

3.5 Подключение к полученному ssl cерверу с помощью curl

curl -k --key client.key --cert client1.crt --url "https://site.com"

Использована опция -k, потому что сертификат в примере самоподписанный

Использованное ПО

Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)
nginx 0.9.3
OpenSSL 0.9.8o 01 Jun 2010

Полезные ссылки

Надеюсь, был кому-то полезен.

P.S. Этот пост был моей первой публикацией 16 января 2011 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).

сертификатов сервера | Документы Microsoft

• 31.08.2016
• На чтение 9 минут

В этой статье

Применимо к: Windows Server 2012 R2, Windows Server 2012

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

Связанные сценарии

В этом документе

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

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

Элементы страницы функций

Элементы панели действий

Диалоговое окно импорта сертификата

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

Мастер запроса сертификата

Используйте мастер Запросить сертификат , чтобы запросить сертификат у центра сертификации (ЦС).

Мастер свойств отличительного имени, страница

Используйте диалоговое окно Distinguished Name Properties , чтобы предоставить информацию о вашей организации внутреннему или внешнему центру сертификации.

Мастер свойств поставщика криптографических служб, страница

Используйте страницу мастера поставщика криптографических служб , чтобы выбрать Microsoft RSA SChannel Cryptographic Provider или Microsoft DH SChannel Cryptographic Provider , чтобы предоставить сертификаты, которые могут шифровать передачи между вашим сервером и клиентами.Кроме того, вы можете настроить уровень безопасности для своей передачи, изменив длину в битах, связанную с поставщиком криптографических услуг.

Мастер имени файла Страница

Используйте диалоговое окно File Name для присвоения имени и сохранения сертификатов в соответствующем месте хранения.

Диалоговое окно полного запроса сертификата

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

Мастер создания сертификата

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

Мастер свойств отличительного имени, страница

Используйте диалоговое окно Distinguished Name Properties , чтобы предоставить информацию о вашей организации внутреннему или внешнему центру сертификации.

Мастер онлайн-сертификации Стр.

Используйте страницу мастера Online Certification Authority Wizard, чтобы определить сервер онлайн-центра сертификации (CA) в вашем домене Windows. Кроме того, предоставьте серверу CA, который вы хотите использовать, понятное имя , чтобы завершить работу мастера Create Domain Certificate Wizard.

Диалоговое окно выбора центра сертификации

Используйте диалоговое окно Select Certification Authority , чтобы выбрать внутренний центр сертификации (CA), который вы хотите использовать.

Диалоговое окно «Создание самозаверяющего сертификата»

Используйте диалоговое окно Create Self-Signed Certificate для создания сертификатов для использования в средах тестирования серверов и для устранения неполадок сторонних сертификатов.

Вы можете просмотреть свойства своего самозаверяющего сертификата на странице Сертификаты сервера .

Диалоговое окно экспорта сертификата

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

Примечание

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

Мастер обновления существующего сертификата

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

Важно

Вы не можете продлить сертификат, срок действия которого уже истек. Если вы попытаетесь обновить сертификат, срок действия которого истек, центр сертификации (ЦС) отклонит запрос, и вы увидите сообщение об ошибке, подобное «Ошибка проверки подписи запроса или сертификата подписи. Требуемый сертификат не соответствует сроку действия при проверке. против текущих системных часов или отметки времени в подписанном файле «. Это сообщение также отображается в узле «Неудачные запросы» выдающего ЦС.Если срок действия вашего сертификата уже истек, запросите новый сертификат вместо обновления существующего.

.Обзор развертывания сертификата сервера

| Документы Microsoft

• 07.08.2020
• 5 минут на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016

Этот раздел содержит следующие разделы.

Компоненты развертывания сертификата сервера

Это руководство можно использовать для установки служб сертификации Active Directory (AD CS) в качестве корневого центра сертификации (ЦС) предприятия и для регистрации сертификатов серверов на серверах, на которых работает сервер политики сети (NPS), служба маршрутизации и удаленного доступа (RRAS). или и NPS, и RRAS.

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

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

Примечание

На приведенной выше иллюстрации показано несколько серверов: DC1, CA1, WEB1 и множество серверов SDN.В этом руководстве представлены инструкции по развертыванию и настройке CA1 и WEB1, а также по настройке DC1, который в этом руководстве предполагается, что вы уже установили его в своей сети. Если вы еще не установили домен Active Directory, вы можете сделать это с помощью Руководства по основной сети для Windows Server 2016.

Для получения дополнительной информации о каждом элементе, изображенном на иллюстрации выше, см. Следующее:

CA1 с ролью сервера AD CS

В этом сценарии корневой центр сертификации (ЦС) предприятия также является выдающим ЦС.ЦС выдает сертификаты серверным компьютерам, которые имеют правильные разрешения безопасности для подачи заявки на сертификат. Службы сертификатов Active Directory (AD CS) установлены на CA1.

Для более крупных сетей или в тех случаях, когда соображения безопасности оправдывают себя, можно разделить роли корневого ЦС и выдающего ЦС и развернуть подчиненные ЦС, которые выдают ЦС.

В наиболее безопасных развертываниях корневой центр сертификации предприятия отключается и физически защищен.

CAPolicy.инф

Перед установкой AD CS необходимо настроить файл CAPolicy.inf с определенными параметрами для вашего развертывания.

Копия RAS и IAS-серверов шаблона сертификата

При развертывании сертификатов серверов вы делаете одну копию шаблона сертификата RAS и серверов IAS , а затем настраиваете шаблон в соответствии с вашими требованиями и инструкциями в этом руководстве.

Вы используете копию шаблона, а не исходный шаблон, так что конфигурация исходного шаблона сохраняется для возможного использования в будущем.Вы настраиваете копию шаблона RAS и IAS-серверов , чтобы центр сертификации мог создавать сертификаты сервера, которые он выдает группам в Active Directory Users and Computers, которые вы укажете.

Дополнительная конфигурация CA1

ЦС публикует список отзыва сертификатов (CRL), который компьютеры должны проверить, чтобы убедиться, что сертификаты, представленные им в качестве подтверждения личности, являются действительными сертификатами и не были отозваны. Вы должны настроить свой центр сертификации с правильным расположением CRL, чтобы компьютеры знали, где искать CRL в процессе аутентификации.

WEB1 с ролью сервера веб-служб (IIS)

На компьютере, на котором выполняется роль сервера веб-сервера (IIS), WEB1, необходимо создать папку в проводнике Windows для использования в качестве расположения для CRL и AIA.

Виртуальный каталог для CRL и AIA

После создания папки в проводнике Windows необходимо настроить папку в качестве виртуального каталога в диспетчере служб IIS, а также настроить список управления доступом для виртуального каталога, чтобы разрешить компьютерам доступ к AIA и CRL после они там публикуются.

DC1 с ролями AD DS и DNS-сервера

DC1 — это контроллер домена и DNS-сервер в вашей сети.

Политика домена по умолчанию групповой политики

После настройки шаблона сертификата в ЦС можно настроить политику домена по умолчанию в групповой политике, чтобы сертификаты автоматически регистрировались на серверах NPS и RAS. Групповая политика настраивается в AD DS на сервере DC1.

Запись ресурса псевдонима DNS (CNAME)

Вы должны создать запись ресурса псевдонима (CNAME) для веб-сервера, чтобы другие компьютеры могли найти сервер, а также AIA и CRL, которые хранятся на сервере.Кроме того, использование записи ресурса CNAME псевдонима обеспечивает гибкость, так что вы можете использовать веб-сервер для других целей, таких как размещение веб-сайтов и FTP-сайтов.

NPS1, на котором запущена служба роли сервера политики сети для роли сервера служб политики сети и доступа

NPS устанавливается при выполнении задач, описанных в Руководстве по работе с основными сетями Windows Server 2016, поэтому перед выполнением задач, описанных в этом руководстве, у вас уже должен быть установлен один или несколько NPS в вашей сети.

Групповая политика применена и сертификат зарегистрирован на серверах

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

Обзор процесса развертывания сертификата сервера

Процесс настройки регистрации сертификата сервера происходит в следующие этапы:

1. На WEB1 установите роль веб-сервера (IIS).

2. На DC1 создайте запись псевдонима (CNAME) для вашего веб-сервера WEB1.

3. Настройте свой веб-сервер для размещения CRL от CA, затем опубликуйте CRL и скопируйте сертификат Enterprise Root CA в новый виртуальный каталог.

4. На компьютере, на котором вы планируете установить AD CS, назначьте компьютеру статический IP-адрес, переименуйте компьютер, присоедините компьютер к домену, а затем войдите на компьютер с учетной записью пользователя, которая является членом Группы администраторов домена и администраторов предприятия.

5. На компьютере, на котором вы планируете установить AD CS, настройте файл CAPolicy.inf с параметрами, специфичными для вашего развертывания.

6. Установите роль сервера AD CS и выполните дополнительную настройку CA.

7. Скопируйте CRL и сертификат CA из CA1 в общую папку на веб-сервере WEB1.

8. В центре сертификации настройте копию шаблона сертификата серверов RAS и IAS. ЦС выдает сертификаты на основе шаблона сертификата, поэтому вам необходимо настроить шаблон для сертификата сервера, прежде чем ЦС сможет выдать сертификат.

9. Настройте автоматическую регистрацию сертификатов сервера в групповой политике. Когда вы настраиваете автоматическую регистрацию, все серверы, которые вы указали для членства в группах Active Directory, автоматически получают сертификат сервера при обновлении групповой политики на каждом сервере. Если вы добавите больше серверов позже, они также автоматически получат сертификат сервера.

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

    Примечание

    Все компьютеры, входящие в домен, автоматически получают сертификат Enterprise Root CA без настройки автоматической регистрации. Этот сертификат отличается от сертификата сервера, который вы настраиваете и распространяете с помощью автоматической подачи заявок. Сертификат ЦС автоматически устанавливается в хранилище сертификатов доверенных корневых центров сертификации для всех компьютеров-членов домена, так что они будут доверять сертификатам, выданным этим ЦС.

11. Убедитесь, что все серверы зарегистрировали действительный сертификат сервера.

.Планирование развертывания сертификата сервера

| Документы Microsoft

• 07.08.2020
• 6 минут на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016

Перед развертыванием сертификатов сервера необходимо запланировать следующие элементы:

План базовой конфигурации сервера

После установки Windows Server 2016 на компьютеры, которые вы планируете использовать в качестве центра сертификации и веб-сервера, вы должны переименовать компьютер, а также назначить и настроить статический IP-адрес для локального компьютера.

Дополнительные сведения см. В Руководстве по основной сети Windows Server 2016.

План доступа к домену

Для входа в домен компьютер должен быть членом домена, а учетная запись пользователя должна быть создана в AD DS перед попыткой входа. Кроме того, для большинства процедур в этом руководстве требуется, чтобы учетная запись пользователя была членом групп «Администраторы предприятия» или «Администраторы домена» в Active Directory «Пользователи и компьютеры», поэтому вы должны войти в ЦС с учетной записью, имеющей соответствующее членство в группе.

Дополнительные сведения см. В Руководстве по основной сети Windows Server 2016.

Спланируйте расположение и имя виртуального каталога на вашем веб-сервере

Чтобы предоставить доступ к списку отзыва сертификатов и сертификату ЦС другим компьютерам, вы должны сохранить эти элементы в виртуальном каталоге на своем веб-сервере. В этом руководстве виртуальный каталог находится на веб-сервере WEB1. Эта папка находится на диске «C:» и называется «pki». Вы можете разместить свой виртуальный каталог на своем веб-сервере в любой папке, которая подходит для вашего развертывания.

Планирование записи псевдонима DNS (CNAME) для веб-сервера

Записи ресурсов псевдонима (CNAME) также иногда называют записями ресурсов канонических имен. С помощью этих записей вы можете использовать более одного имени для указания на один хост, что упрощает выполнение таких задач, как размещение как сервера протокола передачи файлов (FTP), так и веб-сервера на одном компьютере. Например, хорошо известные имена серверов (ftp, www) регистрируются с использованием записей ресурсов псевдонима (CNAME), которые сопоставляются с именем хоста системы доменных имен (DNS), например WEB1, для серверного компьютера, на котором размещены эти службы.

Это руководство содержит инструкции по настройке вашего веб-сервера для размещения списка отзыва сертификатов (CRL) для вашего центра сертификации (CA). Поскольку вы также можете использовать свой веб-сервер для других целей, например, для размещения FTP или веб-сайта, рекомендуется создать запись ресурса псевдонима в DNS для вашего веб-сервера. В этом руководстве запись CNAME называется «pki», но вы можете выбрать имя, подходящее для вашего развертывания.

План настройки CAPolicy.инф

Перед установкой AD CS необходимо настроить CAPolicy.inf в центре сертификации, указав правильную информацию для вашего развертывания. Файл CAPolicy.inf содержит следующую информацию:

  [Версия]
Подпись = "$ Windows NT $"
[PolicyStatementExtension]
Политики = InternalPolicy
[InternalPolicy]
OID = 1.2.3.4.1455.67.89.5
Notice = "Заявление о правовой политике"
URL = https: //pki.corp.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength = 2048
RenewalValidityPeriod = Годы
RenewalValidityPeriodUnits = 5
CRLPeriod = недели
CRLPeriodUnits = 1
LoadDefaultTemplates = 0
AlternateSignatureAlgorithm = 1
  

Для этого файла необходимо запланировать следующие элементы:

• URL .Пример файла CAPolicy.inf имеет значение URL-адреса https://pki.corp.contoso.com/pki/cps.txt . Это связано с тем, что веб-сервер в этом руководстве называется WEB1 и имеет запись ресурса DNS CNAME pki. Веб-сервер также присоединен к домену corp.contoso.com. Кроме того, на веб-сервере есть виртуальный каталог с именем «pki», в котором хранится список отзыва сертификатов. Убедитесь, что значение, указанное вами для URL-адреса в файле CAPolicy.inf, указывает на виртуальный каталог на вашем веб-сервере в вашем домене.

• RenewalKeyLength . Длина ключа обновления по умолчанию для AD CS в Windows Server 2012 составляет 2048. Длина ключа, которую вы выбираете, должна быть как можно большей, при этом обеспечивая совместимость с приложениями, которые вы собираетесь использовать.

• RenewalValidityPeriodUnits . В примере файла CAPolicy.inf значение RenewalValidityPeriodUnits равно 5 годам. Это связано с тем, что ожидаемая продолжительность жизни CA составляет около десяти лет. Значение RenewalValidityPeriodUnits должно отражать общий срок действия CA или максимальное количество лет, на которое вы хотите предоставить регистрацию.

• CRLPeriodUnits . В примере файла CAPolicy.inf значение CRLPeriodUnits равно 1. Это связано с тем, что примерный интервал обновления для списка отзыва сертификатов в этом руководстве составляет 1 неделю. При значении интервала, которое вы указываете с помощью этого параметра, вы должны опубликовать CRL в CA в виртуальном каталоге веб-сервера, где вы храните CRL, и предоставить к нему доступ для компьютеров, находящихся в процессе аутентификации.

• Алгоритм альтернативной подписи .Этот CAPolicy.inf реализует улучшенный механизм безопасности за счет реализации альтернативных форматов подписи. Не следует применять этот параметр, если у вас все еще есть клиенты Windows XP, которым требуются сертификаты от этого ЦС.

Если вы не планируете добавлять какие-либо подчиненные ЦС к своей инфраструктуре открытого ключа в дальнейшем и если вы хотите предотвратить добавление каких-либо подчиненных ЦС, вы можете добавить ключ PathLength в свой файл CAPolicy.inf со значением из 0. Чтобы добавить этот ключ, скопируйте и вставьте в свой файл следующий код:

  [BasicConstraintsExtension]
PathLength = 0
Критический = Да
  

Важно

Не рекомендуется изменять какие-либо другие параметры в CAPolicy.inf, если у вас нет особой причины для этого.

Плановая конфигурация расширений CDP и AIA на CA1

При настройке точки распространения (CDP) списка отозванных сертификатов (CRL) и параметров доступа к информации центра сертификации (AIA) на CA1 вам потребуется имя вашего веб-сервера и имя вашего домена. Вам также потребуется имя виртуального каталога, который вы создаете на своем веб-сервере, где хранятся список отзыва сертификатов (CRL) и сертификат центра сертификации.

Расположение CDP, которое необходимо ввести на этом этапе развертывания, имеет формат:

http: \ / \ / * DNSAlias ​​\ (CNAME \) RecordName *. * Domain * .com \ / * VirtualDirectoryName * \ / .crl.

Например, если ваш веб-сервер называется WEB1, а ваша запись DNS-псевдонима CNAME для веб-сервера — «pki», ваш домен — corp.contoso.com, а ваш виртуальный каталог — pki, расположение CDP:

http: \ / \ / pki.corp.contoso.com \ / pki \ / .crl

Местоположение AIA, которое необходимо ввести, имеет формат:

http: \ / \ / * DNSAlias ​​\ (CNAME \) RecordName *. * Domain * .com \ / * VirtualDirectoryName * \ / \ _ .crt.

Например, если ваш веб-сервер называется WEB1, а ваша запись DNS-псевдонима CNAME для веб-сервера — «pki», ваш домен — corp.contoso.com, а ваш виртуальный каталог — pki, расположение AIA:

http: \ / \ / pki.corp.contoso.com \ / pki \ / \ _ .crt

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

Чтобы опубликовать CRL и сертификат CA из CA в виртуальный каталог веб-сервера, вы можете запустить команду certutil -crl после настройки расположений CDP и AIA в CA. Убедитесь, что вы настроили правильные пути на вкладке CA Properties Extensions , прежде чем запускать эту команду, используя инструкции в этом руководстве.Кроме того, чтобы скопировать сертификат Enterprise CA на веб-сервер, вы должны уже создать виртуальный каталог на веб-сервере и настроить папку как общую папку.

Спланируйте настройку шаблона сертификата сервера на CA

Чтобы развернуть автоматически зарегистрированные сертификаты сервера, необходимо скопировать шаблон сертификата с именем RAS и IAS Server . По умолчанию эта копия называется Копия RAS и IAS Server . Если вы хотите переименовать эту копию шаблона, спланируйте имя, которое вы хотите использовать на этом этапе развертывания.

Примечание

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

.

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

• 07.08.2020
• 2 минуты на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016

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

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

Приведенная ниже процедура включает инструкции по настройке шаблона для выдачи сертификатов всем из следующих типов серверов:

• Серверы, на которых запущена служба удаленного доступа, включая серверы шлюза RAS, которые являются членами группы RAS и IAS-серверов .
• Серверы, на которых работает служба сервера политики сети (NPS), которые являются членами группы RAS и IAS-серверов .

Членство в группе Enterprise Admins и Domain Admins корневого домена является минимумом, необходимым для выполнения этой процедуры.

Для настройки шаблона сертификата

1. На CA1 в диспетчере серверов щелкните Инструменты , а затем щелкните Центр сертификации . Откроется консоль управления Microsoft Management Console (MMC) центра сертификации.

2. В MMC дважды щелкните имя CA, щелкните правой кнопкой мыши Шаблоны сертификатов , а затем щелкните Управление .

3. Откроется консоль шаблонов сертификатов. Все шаблоны сертификатов отображаются на панели сведений.

4. На панели сведений щелкните шаблон RAS и IAS Server .

5. Щелкните меню Action , а затем щелкните Duplicate Template . Откроется диалоговое окно «Свойства шаблона » .

6. Щелкните вкладку Безопасность .

7. На вкладке Безопасность в разделе Группа или имена пользователей щелкните Серверы RAS и IAS .

8. В Разрешения для серверов RAS и IAS в разделе Разрешить убедитесь, что выбран Регистрация , а затем установите флажок Автоматическая регистрация . Щелкните OK и закройте MMC шаблонов сертификатов.

9. В центре сертификации MMC щелкните Шаблоны сертификатов . В меню Action укажите на New , а затем щелкните Certificate Template to Issue .Откроется диалоговое окно Включить шаблоны сертификатов .

10. В Включить шаблоны сертификатов щелкните имя шаблона сертификата, который вы только что настроили, а затем щелкните ОК . Например, если вы не меняли имя шаблона сертификата по умолчанию, щелкните Копия RAS и IAS Server , а затем щелкните ОК .

.