Центр сертификации windows web доступ

Настройка веб-сервера Центра сертификации на MS Windows Server 2012 R2

Настройка веб-сервера Центра сертификации будет заключаться в следущем:

  • корректировка шаблона сертификата веб-сервера;
  • создание сертификата веб-сервера;
  • настройка диспетчера IIS для работы веб-сайта центра сертификации по протоколу SSL.

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

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

В центре сертификации переместиться на Шаблоны сертификатов,
вызвать контекстное меню, нажать на Управление:

В открывшемся окне консоли шаблонов сертификатов выбрать Веб-сервер
и дважды кликнуть на нем мышкой:

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

Закрыть окно центра сертификации.

Создание сертификата для веб-сервера

Запустить оснастку mmc. Для этого нажать правой кнопкой мыши на Пуск, в открывшемся окне выбрать Выполнить. В меню запуска
введите команду MMC:

Добавить оснастку, для этого выбрать меню Файл/Добавить или удалить оснастку:

Выбрать Сертификаты и нажать кнопку Добавить:

В окне Оснастка диспетчера сертификатов выбрать учетной записи компьютера:

Создать настраиваемый запрос, для этого в окне консоли оснастки
сертификаты раскрыть меню Сертификаты (Локальный компьютер/Сертификаты
На строке Сертификаты вызвать контекстное меню Все задачи/Запросить новый сертификат:

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

В закладке Субъект необходимо добавить значения Общее имя и Страна
. Общее имя должно соответствовать имени сервера (например,
SRV15), страна – RU. Нажимаем ОК и Заявка:

Настройка работы веб-сервера Центра сертификации протоколу SSL

Запустить Диспетчер служб IIS:

В левой части окна диспетчера выбрать Default Web Site,
затем в правой части окна – Привязки:

В появившемся окне нажать кнопку Добавить:

В окне Добавление привязки сайта выбрать тип HTTPS и
выбрать из списка созданный SSL сертификат. Назначение
сертификата должно быть Обеспечивает получение идентификации
от удаленного компьютера
:

Закрыть окно. Сделать проверку работы SSL сертификата при доступе на сайт центра сертификации
через браузер. Ввести адрес – https://имя сервера/certsrv, где имя сервера вводим
самостоятельно.

При правильной настройке веб-сервера доступ к сайту будет выполнен без ошибок.

When you install a certificate authority on Windows Server, you can obtain certificates manually via the «mmc» console or automatically via auto-enrollment (via GPOs).
However, you can also install the web interface of this one to be able to request certificates from a web interface.

Note that this can be installed on the same server as your CA or on another server.
However, in this tutorial, we will install it on the same server as our CA to make it easier.

  1. Install your certificate authority’s web interface
  2. Installed certificate authority web interface
  3. Create a certificate template to secure access to your CA’s web interface
  4. Request a certificate to secure your certificate authority’s web interface
  5. Secure access to your CA’s web interface in HTTPS
  6. Block insecure access (HTTP) to your CA’s web interface
  7. Request a certificate for a web server using this web interface
  8. Securing the new web server

To install the web interface of your certificate authority, open the server manager and click on : Add roles and features.

Choose : Role-based or feature-based installation.

Select the server where your CA is installed.
By default, there is only one.

Expand the «Active Directory Certificate Services» section and check the «Certification Authority Web Enrollment» box.

Installing this Active Directory Certificate Services role service will require the installation of a web server (IIS) to be able to access your CA’s web interface.
Accept the addition of these features.

Then, click Next at each step to use the default settings.

Click Install.

Wait while installing the «Web Server (IIS)» feature required for the operation of the web interface of your certification authority.

At the bottom, you will see that the wizard will also install the «Certificate Authority Web Enrollment» role service that is part of the «Active Directory Certificate Services» role.

Once the installation is complete, click on the «Configure Active Directory Certificate Services on the destination server» link that appears.

The «AD CS Configuration» wizard will appear.
Just click Next.

Check the «Certification Authority Web Enrollment» box (which corresponds to the role service you just installed) and click Next.

As you can see, there are no settings to change.
Just click on : Configure.

The «Configuration succeeded» message appears.
Click Close.

The Add Roles and Features Wizard tells you that the Active Directory Certificate Services role services are configured.
Click Close.

2. Installed certificate authority web interface

If you open the start menu of your server, you will see that the IIS manager is present.

In this IIS Manager, you will find a Default Web Site containing 2 folders :

  • CertEnroll : contains your certification authority’s revocation lists. These will therefore also be accessible via the HTTP protocol (if this option is enabled in the properties of your certification authority).
  • CertSrv : corresponds to the «.asp» scripts representing the web interface of your certification authority from which you can, for example, request user certificates, custom certificates (from a base 64 certificate request) or download the certification authority’s certificate.

Access the web interface of your certification authority by typing the «http://[domain name of the server where it’s installed]/certsrv» address.
Which gives in our case : «http://ca.informatiweb.lan/certsrv».

As you can see, by default, to access it, you will first need to authenticate.
Log in with the domain administrator account, for example. Indeed, by default, this user can enroll several types of certificates thanks to the pre-installed certificate templates. Including the one to secure web servers.

If IE Enhanced Security Configuration is enabled, you will need to click «Add» to access this web interface.

Note : IE Enhanced Security Configuration can be easily disabled from the «Local Server» section of the Server Manager.

Then, confirm the addition of this website in the «Trusted Sites» zone of Internet Explorer.

Then, the «Microsoft Active Directory Certificate Services — [your certificate authority name]» web interface will appear.
As you can see, through this web interface, you will be able to request certificates, as well as download its certificate.

Click on the link : Request a certificate.

Then, click on : advanced certificate request.

But, as you can see, you will need to secure access to this web interface (using the HTTPS protocol) to be able to request certificates through it.

Plain Text

In order to complete certificate enrollment, the Web site for the CA must be configured to use HTTPS authentication.

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

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

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

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

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

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

Запуск диспетчера сервера

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

Диспетчер сервера

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

Установка ролей и компонентов

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

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

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

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

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

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

Веб-служба регистрации сертификатов

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

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

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

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

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

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

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

центр сертификации предприятия

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

Тип центра сертификации

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

создать новый закрытый ключ

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

параметры шифрования

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

имя центра шифрования

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

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

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

Место расположения базы данных

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

Успешное завершение настройки

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

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

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

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

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

Тип проверки подлинности

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

Учетная запись службы CES

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

Выбор сертификата

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

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

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

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

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

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

Включите режим обновления на останове ключей

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

Настройка службы выполнена

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

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

Консоль mmc

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

Добавить или удалить оснастку

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

Учетной записи компьютера

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

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

Оснастка добавлена

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

Перечень сертификатов

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

Запрос сертификата с новым ключом

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

перед началом работы

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

Заявка на выпуск сертификата

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

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

диспетчер служб IIS

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

изменить привязки

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

Настройка веб-интерфейса

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

Обзор сайта

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

Web-интерфейс центра сертификации

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

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

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

Окно оснастки шаблоны сертификатов

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

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

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

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

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

Общие свойства шаблона

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

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

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

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

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

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

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

Обработка запроса

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

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

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

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

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

Вкладка шифрование

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

Вкладка безопасность

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

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

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

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

Первая часть серии

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

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

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

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

Общий план развёртывания

Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:

  1. Контроллер домена — необходим для функционирования домена Active Directory;
  2. Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
  3. Корневой ЦС — будет выполнять функции корневого ЦС;
  4. Подчинённый ЦС — будет выполнять функции издающего ЦС.

Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

Подготовка контроллера домена

Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.

Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

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

  • Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment
  • User Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment

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

Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.

Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:

Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom" 

Подготовка веб-сервера

На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.

  • Установка службы IIS

Для установки службы IIS можно воспользоваться следующей командой:

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

  • Создание папки PKIdata

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:\InetPub\wwwroot\PKIdata

New-Item -ItemType Directory -Path C:\InetPub\wwwroot -Name PKIdata -Force
New-SmbShare -Path C:\inetpub\wwwroot\PKIdata -Name PKI -FullAccess everyone

После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

  • Создание веб-сайта

Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:\inetpub\wwwroot\PKIdata
New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:\inetpub\wwwroot\PKIdata

  • Включение поддержки Delta CRL

В нашем сценарии издающий ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию, IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Для этого необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Установка корневого ЦС

Фактическая установка ЦС будет включать в себя несколько этапов:

  1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
  2. Установка компонента ЦС;
  3. Выполнение постустановочной конфигурации;
  4. Проверка установки.

Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:

Название параметра Значение параметра
Сервер ЦС
Класс ЦС Standalone CA
Тип ЦС Root CA
Сертификат
Имя сертификата Contoso Lab Root Certification authority
Дополнительный суффикс OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа RSA#Microsoft Software Key Storage Provider
Длина ключа 4096 бит
Алгоритм подписи SHA256
Срок действия 15 лет

В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.

Предварительная конфигурация

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%\CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType StandaloneRootCA `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod "years" `
    -ValidityPeriodUnits 15 `
    -DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog")

Итоговая настройка

После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

Название параметра Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов 15 лет
Точки публикации CRT 1) По-умолчанию
2) C:\CertData\contoso-rca<CertificateName>.crt
3) IIS:\InetPub\PKIdata\contoso-rca<CertificateName>.crt*
Точки распространения CRT 1) cdp.contoso.com/pki/contoso-rca<CertificateName>.crt
Точки публикации CRL 1) По-умолчанию
2) C:\CertData\contoso-rca<CRLNameSuffix>.crt
3) IIS:\InetPub\PKIdata\contoso-rca<CRLNameSuffix>.crt*
Точки распространения CRL 1) cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt
Сертификат
Состав CRL Base CRL
Base CRL
Тип Base CRL
Срок действия 6 месяцев
Расширение срока действия 1 месяц
Алгоритм подписи SHA256
Публикация в AD Нет

* — копируется на сервер IIS

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Root CA post-installation script                               ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=C:\CertData\contoso-rca%%8.crl
SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl
SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt

:: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка
:: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows.
md C:\CertData

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl\n1:%CrlLocal%\n2:%CDP%"

certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-rca.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-rca.crt C:\CertData

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 15
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Months"
certutil -setreg CA\CRLOverlapUnits 1

:: Отключаем дифференциальные списки отзыва (или Delta CRL)
certutil -setreg CA\CRLDeltaPeriodUnits 0

:: Отключаем генерацию кросс-сертификатов
certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «\n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

Название галочки в MMC Числовое значение Название галочки в MMC Числовое значение
Publish CRLs to this location. 1 Include in the AIA extension of issued
certificates.
2
Include in the CDP extension of issued certificates. 2 Include in the Online Certificate Status. Protocol (OCSP) extension. 32
Include in CRLs. Clients use this to find Delta CRL locations. 4
Include in all CRLs. Specifies where to publish in AD DS when publishing manually. 8
Publish Delta CRLs to this location. 64
Include in the IDP extension of issued CRLs. 128

Если взять путь для CDP: 1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

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

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

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

Переменная в редакторе расширений CDP и AIA Переменная в скрипте Где используется Значение
<ServerDNSName> %1 CDP/AIA Полное ДНС имя сервера ЦС
<ServerShortName> %2 CDP/AIA Короткое (NetBIOS) имя сервера ЦС
<CaName> %3 CDP/AIA Имя ЦС (атрибут CN в сертификате)
<CertificateName> %4 AIA Индекс сертификата ЦС. Используется только при обновлении сертификата ЦС.
<ConfigurationContainer> %6 CDP/AIA Путь к configuration naming context в Active Directory
<CATruncatedName> %7 CDP/AIA Укороченное (санитизированное) имя сертификата ЦС. В общем случае будет совпадать с полным именем ЦС
<CRLNameSuffix> %8 CDP Индекс ключа ЦС, которым был подписан данный CRL. Используется при обновлении ключевой пары ЦС.
<DeltaCRLAllowed> %9 CDP Добавляет суффикс для Delta CRL (знак «+»).
<CDPObjectClass> %10 CDP Класс объекта в Active Directory
<CAObjectClass> %11 CDP/AIA Класс объекта в Active Directory

В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной , только здесь будет указываться индекс ключевой пары ЦС.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

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

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

После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

  • Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
  • Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
  • Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Если всё хорошо, тогда скопируйте содержимое папки C:\CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish path\contoso-rca.crt RootCA

Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root path\contoso-rca.crt

Установка издающего ЦС

Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

  1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
  2. Установка компонента ЦС;
  3. Выполнение постустановочной конфигурации;
  4. Проверка установки и конфигурации.

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

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

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

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

; заголовок INI файла
[Version]
Signature= "$Windows NT$"

; указываем список политик, которые будут включены в сертификат ЦС. В нашем
; случае будет одна политика под названием AllIssuancePolicies.
[PolicyStatementExtension]
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
[AllIssuancePolicy]
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
[BasicConstraintsExtension]
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
[certsrv_server]
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0

Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

Название параметра Значение параметра
Сервер ЦС
Класс ЦС Enterprise CA
Тип ЦС Subordinate CA
Автоматическая загрузка шаблонов Нет
Сертификат
Имя сертификата Contoso Lab Issuing Certification authority
Дополнительный суффикс OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа RSA#Microsoft Software Key Storage Provider
Длина ключа 4096 бит
Алгоритм подписи SHA256
Срок действия 15 лет (определяется вышестоящим ЦС)
Политики выдачи 1) Имя: All Issuance Policies
OID=2.5.29.32.0
URL=http://cdp.contoso.com/pki/contoso-cps.html
Basic Constraints isCA=True (тип сертификата — сертификат ЦС)
PathLength=0 (запрещается создание других промежуточных ЦС под текущим ЦС).

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType EnterpriseSubordinateCa `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256

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

 # отправляем запрос на ЦС.
certreq -submit 'C:\CA-01.contoso.com_Contoso Lab Issuing Certification authority.req'
# предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде
# в моём случае это номер 2
certutil -resubmit 2
# после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер
# запроса, который был указан после выполнения первой команды
certreq -retrieve 2 C:\subca.crt

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

certutil -installcert c:\subca.crt
net start certsvc

Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

Итоговая настройка

По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

Аналогичная таблица составляется и для издающего ЦС.

Название параметра Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов Максимально: 5 лет (остальное контролируется шаблонами сертификатов)
Публикация в AD (контейнеры) AIA
NTAuthCertificates
Состав CRL Base CRL
Delta CRL
Точки публикации CRT 1) По-умолчанию
2) \\IIS\PKI\contoso-pica<CertificateName>.crt
Точки распространения CRT 1) cdp.contoso.com/pki/contoso-pica<CertificateName>.crt
Точки публикации CRL 1) По-умолчанию
2) \\IIS\PKI\contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
Точки распространения CRL 1) cdp.contoso.com/pki/contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
Base CRL
Тип Base CRL
Срок действия 1 неделя
Расширение срока действия По умолчанию
Алгоритм подписи SHA256
Публикация в AD Нет
Delta CRL
Тип Delta CRL
Срок действия 1 день
Расширение срока действия По-умолчанию
Алгоритм подписи SHA256
Публикация в AD Нет

За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Issuing CA post-installation script                            ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=\\IIS\PKI\contoso-pica%%8%%9.crl
SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl
SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:%CrlLocal%\n6:%CDP%"

certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в сетевую папку
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-pica.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-pica.crt \\IIS\PKI

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
:: базовый CRL
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "weeks"

:: Delta CRL
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "days"

:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127

:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах 
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"

:: Включаем поддержку расширения OcspRevNoCheck, если планируется установка
:: сетевого ответчика (Online Responder или OCSP сервера)
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

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

После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

  • Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
  • Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
  • Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку Enterprise PKI Health (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

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

Рекомендации

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

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

Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке Certificate Templates MMC (certtmpl.msc). Рекомендации по шаблонам сертификатов:

Использование готовых шаблонов сертификатов

Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon. Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.

Версия шаблона

Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:

Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на .NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).

Успешно такие сертификаты смогут использовать приложения, которые используют не .NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.


Поля Subject и Subject Alternative Names

Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.

Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».

Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.

Права на шаблоны сертификатов

Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.

Обновление сертификатов ЦС

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

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

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

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

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

Порядок обновления ЦС

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

Генерация ключей при обновлении сертификатов ЦС

При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

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

  • Certificate validation fails when a certificate has multiple trusted certification paths to root CAs.
  • «0x80092013, CRYPT_E_REVOCATION_OFFLINEA» error message when you try to verify a certificate that has multiple chains in Windows Server 2008 or in Windows Vista.

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

Резервное копирование

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

Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:

  • Оснастка Certification Authority MMC (certsrv.msc);
  • Утилита certutil.exe с параметром -backup.

С ними можно сделать резервную копию для ключевой пары ЦС и базы данных. Однако эти инструменты не позволяют делать резервную копию настроек ЦС. Эти операции необходимо выполнять вручную. Все настройки ЦС находятся в реестре по следующему пути:

HKLM\System\CurrentControlSet\Services\CertSvc

При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.

Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:

  • Ключи и сертификаты ЦС;
  • База данных ЦС;
  • Настройки ЦС из реестра;
  • Предустановочный конфигурационный файл;
  • Установочные и конфигурационные скрипты.

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

Об авторе

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

Создание шаблона. 

Откроем на сервере «Центр сертификации» управления шаблонами. 

#> certsrv.msc

Выберем шаблон и сделаем копию под наши потребности.

Нужно разрешить экспортировать закрытый ключ. У нас может быть и windows server и Linux. Для Windows серверов можно снять эту галочку для большей безопасности, но тогда ключи должны генерироваться на том сервере на котором и будут использоваться.    

Сертификаты должны быть одобрены перед тем как выпустить.  

Дополнительные свойства предоставляются в самом запросе. Из основного  «Subject Alternative Names» chrome без этого дополнения выдает предупреждения.  

И на последок, разрешения. Только администраторы домена имеют право на «Заявка». (Запрос на выпуск сертификата). Если нужно добавьте соответствующую группу.   

Добавим созданный шаблон в список доступных шаблонов.  

Создание ключа та формирование запроса к Центру сертификации для Linux web сервера.

Через certlm.msc или mmc (Использую для этого windows 10 но можно с любого компьютера в домене, который имеют доступ)

certlm.msc — работает начиная с windows 2012 и выше. Если нет, используйте mmc. 

   Выбираем созданный шаблон. Если по каким-то причинам нет списков шаблонов. Проверьте Firewall (на сервере центра сертификации должны быть открыты порты DCE-RPC (tcp\udp:135) и RPC dynamic ports (tcp:49152-65535)   ) или пути следование до сервера. 

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

  Будем создавать для web сервера test.print.local

SAN(Subject Alternative Names):

— test.print.local

— test

— 10.210.101.5

При использовании SAN — это позволит, если даже я зайду по ip не получать предупреждения в chrome об некорректном сертификате. 

Основные атрибуты находятся сверху CN,C,L,O,OU,S. Дополнительно создадим DNS (test.print.local, test), IP (10.210.101.5)

Сохраним запрос в файл, для передачи в Центр сертификации.

 Запустим Powershell 

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

#> certreq.exe -submit .\test.req

Тоже самое можно сделать из консоли certsrv.msc (на сервере ЦС)

Ответственный администратор Центра сертификации должен принять запрос. Самый ответственный шаг. :)  

После этого возвращаемся в powershell и запрашиваем подписаний сертификат. 

  #> certreq -retrieve 51

51 — получен на первом шаге. 

  Импортируем подписаний сертификат на тот сервер на котором ми создавали и заполняли шаблон.

Экспортируем ключ и сертификат для передачи на linux сервер. 

Сохранил в файл test.pfx и копировал его на Linux сервер.

  На сервере Linux конвертируем test.pfx в pem формат понятный для apache. 

Сохраним сертификаты в файл test.crt в pem формате  

># openssl pkcs12 -in test.pfx -out test.crt -clcerts -nokeys  -nodes

Получаем ключ 

># openssl pkcs12 -in test.pfx -out test.key -nocerts -nodes

Получены файли уже можна использовать в apache

test.crt

test.key

Тестируем 

Открываем chrome и проверяем. 

Создание ключа та формирование запроса к Центру сертификации для Linux web сервера из Linux окружения.

Готовим файл cnf для openssl 

test.cnf

test.cnf

 [req]

distinguished_name = req_distinguished_name

req_extensions = v3_req

prompt = no

[req_distinguished_name]

C = UA

ST = Kiev

L = Kiev

O = Univet

OU = IT

CN = test.print.localm

[v3_req]

keyUsage = keyEncipherment, dataEncipherment

extendedKeyUsage = serverAuth

subjectAltName = @alt_names

[alt_names]

DNS.1 = test.print.local

DNS.2 = test

IP.1  = 10.210.101.5

Генерируем ключ и запрос на центр сертификации. 

>#  openssl req -out test-linux.csr -newkey rsa:2048 -nodes -keyout test.key -config test.cnf

Полученный файл test-linux.csr копируем на компьютер с windows, который имеет доступ до центра сертификации. Запускаем Powershell

attrib  — выбираем нужный шаблон «certificatetemplate:test»

test — имя шаблона

 #> certreq.exe -attrib  «certificatetemplate:test» -submit .\test-linux.csr

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

#> certreq -retrieve 52 

На ЦС ми видим наш сертификат 

Полученный результат можно передавать на сервер c Linux. 

Ссылки:

https://geekflare.com/san-ssl-certificate/

https://ss64.com/nt/certreq.html

https://www.citrix.com/blogs/2015/04/10/how-to-create-a-csr-for-a-san-certificate-on-netscaler/

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Dism windows 10 с установочного диска
  • Windows server std 2019 64bit russian 1pk dsp oei dvd 16 core
  • Фильтр smartscreen сейчас недоступен windows 10 как исправить
  • Windows 10 не удалось подключиться к принтеру 0x00004005
  • Синий экран windows 7 mac