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

А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере 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 ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate Services Client – Auto-Enrollment
• User ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate 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:InetPubwwwrootPKIdata

New-Item -ItemType Directory -Path C:InetPubwwwroot -Name PKIdata -Force
New-SmbShare -Path C:inetpubwwwrootPKIdata -Name PKI -FullAccess everyone

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

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

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

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:inetpubwwwrootPKIdata
New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:inetpubwwwrootPKIdata

• Включение поддержки 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. Проверка установки.

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

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

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

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или 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 "System32CertLog")

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

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

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

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

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

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Root CA post-installation script                               ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=C:CertDatacontoso-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 CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8.crln1:%CrlLocal%n2:%CDP%"

certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"

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

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

:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CACRLPeriodUnits 180
certutil -setreg CACRLPeriod "Days"
certutil -setreg CACRLOverlapPeriod "Months"
certutil -setreg CACRLOverlapUnits 1

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

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

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

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

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

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

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

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

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

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

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

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

В нашем конкретном случае будут использоваться только две переменные: <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 pathcontoso-rca.crt RootCA

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

Certutil -f -addstore Root pathcontoso-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

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

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета 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. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

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

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

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Issuing CA post-installation script                            ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=\IISPKIcontoso-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 CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8%%9.crln65:%CrlLocal%n6:%CDP%"

certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"

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

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

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

:: Delta CRL
certutil -setreg CACRLDeltaPeriodUnits 1
certutil -setreg CACRLDeltaPeriod "days"

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

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

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

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg cacspCNGHashAlgorithm 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.

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

HKLMSystemCurrentControlSetServicesCertSvc

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

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

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

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

Об авторе

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

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

Для настройки необходим компьютер с установленной операционной системой Windows 2019 Server Rus и драйверами Рутокен, а также дистрибутив этой ОС.

Все описанные далее действия производятся с правами администратора системы.

В качестве примера используется учетная запись Administrator.

Этапы установки и настройки Служб сертификации:

1 этап: Установка Служб сертификации.

2 этап: Добавление шаблонов сертификатов в Центр Сертификации.

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

Установка Служб сертификации

Для установки Служб сертификации:

1. Откройте Диспетчер серверов.
2. Щелкните по названию пункта меню Управление и выберите пункт Добавить роли и компоненты.
   
   
3. В окне  Мастер добавления ролей и компонентов ознакомьтесь с информацией и нажмите Далее.
   
   
4. Установите переключатель в положение Установка ролей или компонентов и нажмите Далее.
   
   
5. Установите переключатель в положение Выберите сервер из пула серверов.
6. В таблице Пул серверов щелкните по имени необходимого сервера.
7. Нажмите Далее.
   
   
8. Установите флажок Службы сертификатов Active Directory.
   
   
9. В появившемся окне нажмите Добавить компоненты. В результате флажок отобразится рядом с названием выбранной роли сервера.
   
   
10. Нажмите Далее.
11. В окне для выбора компонентов нажмите Далее.
    
    
12. Ознакомьтесь с информацией и нажмите Далее.
    
    
13. Установите флажок Центр сертификации и нажмите Далее.
    
    
14. Чтобы запустить процесс установки нажмите Установить.
    
    
15. Дождитесь завершения процесса установки и нажмите Закрыть.
    
    
16. В левой части окна Диспетчер серверов щелкните по названию пункта Службы сертификации Active Directory.
17. Щелкните по восклицательному знаку.
18. Щелкните по ссылке Настроить службы сертификатов Active Directory.
    
    
19. Ознакомьтесь с информацией и нажмите Далее.
    
    
20. Установите флажок Центр сертификации и нажмите Далее.
    
    
21. Установите переключатель рядом с названием необходимого варианта установки ЦС (в данном примере выбирается ЦС предприятия) и нажмите Далее.
    
    
22. Установите переключатель рядом с названием типа ЦС (в данном примере выбирается Корневой ЦС, поскольку это будет основной центр сертификации в домене). Нажмите Далее.
    
    
23. В окне для указания типа закрытого ключа укажите секретный ключ, который будет использоваться для центра сертификации (в данном примере выбирается пункт Создать новый закрытый ключ, поскольку ранее не был создан секретный ключ для центра сертификации). Нажмите Далее.
    
    
24. В следующем окне для указания параметров шифрования в раскрывающемся списке Выберите поставщик служб шифрования выберите криптопровайдер.
25. В раскрывающемся списке Длина ключа выберите необходимое значение.
26. Щелкните по названию необходимого хеш-алгоритма.
27. Нажмите Далее.
    
    

28. В окне для указания имени ЦС введите значения всех полей и нажмите Далее.
    
    

    Введенные здесь данные носят информативный характер. Рекомендуется их внести. Аббревиатуры несут следующий смысл: «O» — Organization, «OU» — Organization Unit, «L» — City (Location), «S» — State or province, «C» — Country/region, «E» — E-mail.

29. Введите период действия сертификата для создания ЦС.
    
    

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

30. В поле Расположение базы данных сертификатов введите путь до базы данных сертификатов и нажмите Далее.
    
    
31. Ознакомьтесь с информацией и нажмите Настроить.
    
    
32. Дождитесь завершения процесса установки и нажмите Закрыть.
    
    

Добавление шаблонов сертификатов в Центр Сертификации

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

1. Откройте Панель управления.
2. Два раза щелкните по названию пункта Администрирование.
3. Два раза щелкните по названию оснастки Центр сертификации.
   
   
4. Правой кнопкой мыши щелкните по названию папки Шаблоны сертификатов и выберите пункт Управление.
   
   
5. Правой кнопкой мыши щелкните по названию шаблона Пользователь со смарт-картой и выберите пункт Скопировать шаблон. Откроется окно Свойства нового шаблона.
   
   
   
   

6. Выберите следующие настройки:
   
   
   
   

   Значение параметра Минимальный размер ключа должен быть не менее 1024.

   
   

   
   

   
   

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

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

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

1. Нажмите комбинацию клавиш Windows + X и выберите пункт меню Выполнить.
2. Введите команду «mmc» и нажмите ОК.
   
   
3. В окне Консоль 1 выберите пункт меню Файл и подпункт Добавить или удалить оснастку…
   
   
4. В левой части окна Добавление и удаление оснастки щелкните по названию Сертификаты.
5. Нажмите Добавить.
   
   
6. В открывшемся окне установите переключатель моей учетной записи пользователя и нажмите Готово.
   
   
7. В окне Добавление и удаление оснасток нажмите ОК.
8. В левой части окна Консоль1 щелкните по названию папки Личные.
9. Щелкните по названию папки Сертификаты.
10. В правой части окна щелкните правой кнопкой мыши в свободном месте окна.
11. Выберите пункт Все задачи и подпункт Запросить новый сертификат…
    
    
12. В окне Регистрация сертификатов ознакомьтесь с информацией и нажмите Далее.
    
    
13. Нажмите Далее.
    
    
14. Установите флажок Администратор и нажмите Заявка.
    
    
15. Нажмите Готово.
    
    
16. В левой части окна Консоль1 щелкните по названию папки Личное.
17. Щелкните по названию папки Сертификаты.
18. В правой части окна щелкните правой кнопкой мыши в свободном месте окна.
19. Выберите пункт Все задачи и подпункт Запросить новый сертификат…
    
    
20. В окне Регистрация сертификатов ознакомьтесь с информацией. Нажмите Далее.
21. Нажмите Далее.
22. Установите флажок Агент регистрации и нажмите Заявка.
    
    
23. Нажмите Готово.
24. В левой части окна Консоль1 щелкните по названию папки Личное.
25. Правой кнопкой мыши щелкните по названию папки Сертификаты и выберите пункт Все задачи.
26. Выберите подпункт Дополнительные операции.
27. Выберите подпункт Зарегистрироваться от имени…
    
    
28. Ознакомьтесь с информацией и нажмите Далее.
29. Нажмите Далее.
30. Нажмите Обзор.
    
    
31. Щелкните по имени сертификата типа Агент регистрации (чтобы определить тип сертификата откройте свойства сертификата).
32. Нажмите ОК.
    
    
33. Нажмите Далее.
    
    
34. Установите переключатель в положение Пользователь с RuToken и нажмите Далее.
    
    
35. В окне Регистрация сертификатов нажмите Обзор.
    
    
36. В поле Введите имена выбираемых объектов введите имя пользователя, которому будет выписан сертификат типа Пользователь с RuToken.
37. Нажмите Проверить имена.
    
    
38. Нажмите ОК.
    
    
39. Поле Имя пользователя или псевдоним заполнится автоматически.
40. Нажмите Заявка.
    
    
41. Введите PIN-код Пользователя и нажмите ОК.
    
    
42. Нажмите Закрыть.
    
    
43. В результате сертификат типа Пользователь с RuToken выписан и сохранен на токене.
44. Чтобы просмотреть свойства этого сертификата нажмите Просмотреть сертификат.
    
45. Чтобы закрыть окно сертификата нажмите ОК.
46. Аналогичным способом выпишите сертификаты для всех пользователей, которым они необходимы. Пользователю Администратор так же необходимо выписать сертификат типа Пользователь с RuToken.
47. В окне Консоль1 выберите пункт: Файл — Добавить или удалить оснастку.
    
    
48.  В окне для добавления и удаления оснастки выберите в списке доступных оснасток пункт Сертификаты.
    
49. Установите переключатель учетные записи компьютера.
    
50. Выберите пункт: Корень консоли — Сертификаты — Личные — Сертификаты — Все задачи — Запросить новый сертификат.
    
    
51. Установите галочку Проверка подлинности контроллера домена и нажмите Заявка.
    

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

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

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

1. Мастер импорта сертификатов

Если сертификат имеет расширение .crt, то его достаточно запустить двойным кликом:

В открывшемся окне нажмите кнопку «Установить сертификат»:

Выберите один из вариантов:

• «Текущий пользователь» — сертификат будет иметь эффект только для одного пользователя
• «Локальный компьютер» — сертификат будет иметь эффект для всех пользователей данного компьютера

Выберите «Пометить все сертификаты в следующие хранилища»:

Нажмите кнопку «Обзор» и выберите «Доверенные корневые центры сертификации»:

Нажмите «Далее»:

Нажмите «Готово»:

Сообщение об успешном импорте:

Теперь сертификат будет доступен в Менеджере Сертификатов:

2. Добавление root CA сертификата в Менеджере Сертификатов

Чтобы открыть Менеджер Сертификатов нажмите Win+r, введите в открывшееся поле и нажмите Enter:

certmgr.msc

Кликните правой кнопкой мыши по пункту «Доверенные корневые центры сертификации», выберите пункт «Все задачи» → «Импорт»:

Нажмите «Далее»:

Укажите папку и имя файла:

Нажмите «Далее»:

Всё готово:

Подтвердите:

Теперь действительно всё готово:

Только что импортированный сертификат в Менеджере Сертификатов:

Как добавить корневой сертификат в доверенные в Windows в веб браузеры

Chrome, Chromium, Opera и сделанные на их основе веб браузеры используют общесистемные корневые CA сертификаты. То есть для добавления новых доверенных CA достаточно добавить их в систему, как это показано выше.

Firefox использует исключительно своё хранилище. Для добавления корневых сертификатов CA в Firefox нужно сделать так:

• В настройках Firefox: Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:

Нажмите кнопку «Импортировать»:

Выберите файл с сертификатом.

Укажите, какие полномочия вы даёте этому сертификату:

Для глубокого понимания OpenSSL смотрите также полное руководство: «OpenSSL: принципы работы, создание сертификатов, аудит».

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

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

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

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

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

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

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

• VPN-сервера.

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

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

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

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

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

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

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

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

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

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

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

2. В разделе «Установка компонентов» проверяем, что добавлен «Криптопровайдер уровня ядра ОС»; (рис. 1)

Криптопровайдер уровня ядра ОС необходим для работы криптопровайдера
в службах и ядре Windows.

3.  В следующем окне оставляем пункты:

• Зарегистрировать считыватель «Реестр» (позволит сохранять контейнеры ключей в реестр);

• Усиленный контроль использования ключей;

• Не разрешать интерактивные сервисы Windows;

4. Также «КриптоПро» предложит добавить сертификаты своих центров сертификации;

5. Устанавливаем, перезагружаемся.

Установка центра сертификации (Standalone CA Windows Server 2019)

Непосредственно перед самой установкой коротко объясню особенности Standalone CA:

• Не интегрирован с Active Directory (а он нам и не нужен);

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

• Пользователь сам вводит идентификационную информацию во время запроса сертификата;

• Не поддерживает шаблоны сертификатов (из-за этого всплывут некоторые моменты, которые раскрою в процессе развертывания).

Начинаем:

1. Измените имя компьютера до установки роли, после это будет сделать невозможно. «Далее (Next)» (рис.2): 

2. Добавляем роль в «Диспетчере серверов» (Server Manager), «Далее (Next)» (рис. 3):

2.1. «Установка ролей и компонентов (Add roles and features wizard)». Нажимаем «Далее (Next)» — «Далее (Next)»;

2.2. «Тип установки: Установка ролей и компонентов (Installation type: Role-based or features-based installation». «Далее (Next)»;

2.3. «Выбор сервера (Server selection)». В нашем случае среди предложенных будет один сервер и имя компьютера. «Далее (Next)» (рис. 4);

2.4. «Роли сервера (Server roles). Здесь необходимо отметить две роли: Служба сертификатов Active Directory (Certificate Services Active Directory), Веб-сервер IIS (Web-server IIS);

Во всплывающем окне перечня нажимаем «Добавить компонент (Add features)» — «Далее (Next)»;

2.5. «Компоненты (Features) оставляем как есть — «Далее (Next)» ;

2.6. «Служба ролей (Role Services)» ЦС, необходимо выбрать:

• «Центр сертификации (Certification Authority)»,

• «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

Сетевой автоответчик (Online responder) добавим уже после развертывания ЦА, в противном случае могут возникнуть проблемы. 

2.7. В «Служба ролей (Role Services)» веб-сервера оставляем всё предложенное автоматически — «Далее (Next)»;

2.8. «Подтверждение (Confirmation).

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

3. После установки роли центра сертификации необходимо его настроить
(рис. 5). Выбираем: 

3.1. «Настроить службы сертификатов Active Directory (Configure Active Directory-Certificate Services)

3.2. Указываем учетные данные. Так как мы развертываем Standalone центр сертификации, не нужно состоять в группе «Администраторов предприятия (Enterprise Administrators)» — «Далее (Next)»;

3.3. Выбираем установленные службы ролей для настройки (Select role services to configure) ЦС: «Центр сертификации (Certification Authority)», «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

3.3.1. При выборе центра сертификации появится окно выбора ключевого носителя – КриптоПРО CSP, в качестве носителя для создания контейнера cngWorkAround используем хранилище ключей реестра Windows – Реестр. (рис. 6)

3.4. Указываем вариант установки ЦС (Specify the setup type of the CA):
Автономный центр сертификации (Standalone CA). «Далее (Next)»;

3.5. Указываем тип ЦС (Specify the type of CA) – Корневой ЦС (Root CA). «Далее (Next)»;

3.6. Необходимо создать закрытый ключ ЦС, чтобы он мог создавать и выдавать их клиентам. Для этого выбираем «Создать новый закрытый ключ (Create a new private key)».

В качестве поставщика службы шифрования выбираем один из трёх предложенных (не забывайте, что 2001 год уже устарел) Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider с длиной 512 и открытого ключа 1024 бита. (рис.7)

И обязательно подтверждаем: «Разрешить взаимодействие с администратором, если ЦС обращается к закрытому ключу (Allow administrator interaction when the private key is accessed by the CA)»;

3.7. Укажите имя центра сертификации и суффиксы различающего имени, данные суффиксы будут отображаться в составе сертификата в графе «Издатель (Issuer)».

СN = Certificate Name, O = Organization, L = Locale, S = Street, C = Country, E = E-mail; (рис.

3.8. Указываем необходимый «срок годности (validaty period)» корневого сертификата (в нашем случае было выбрано 15 лет). «Далее (Next)»;

3.9. Указываем расположение баз данных сертификатов (certificate database location). «Далее (Next)»;

3.10. В окне «Подтверждения (Confirmation) сверяем введённую информацию — «Настроить (Configure)»

3.11. Появится окно выбора носителя для создания контейнера нашего ЦС.

Где хранятся сами контейнеры ключей:

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

3.13. После введите пароль на доступ к закрытому ключу.

3.14. Далее появится окно результатов об успешной установке компонентов (рис.

Настройка веб-сервера IIS

Теперь необходимо выполнить некоторые настройки веб-сервера: прицепить сертификат (самоподписанный или выпущенный нашим же ЦА). Кстати, он уже работает. В качестве примера выпустим самоподписанный сертификат.

1. Откроем Диспетчер служб IIS (Manager IIS) — Сертификат сервера (Server Certificates) (рис. 9);

1.1. В открывшемся окне в панели «Действия (Actions)» выберем – «Создать самоподписанный сертификат (Create Self-Signed Certificate);

1.2. Выбираем тип «Личный (Personal) и указываем «Имя сертификата (Friendly Name)»

1.3. Теперь необходимо привязать этот сертификат для доступа по https к веб-серверу.

1.3.1. Переходим «Сайты (Sites)» — Default Web Site – Bindings – добавить (Add) — выбрать https – и выбрать самоподписанный SSL-сертификат.

Также сертификат вы можете выпустить следующим образом:
На этой же панели создайте запрос (Create certificate request) для выпуска сертификата через наш ЦА и дальнейшей его загрузки в IIS (Complete Certificate Request). Но это по желанию.

Пример запроса (request) для формирования запроса вручную

[NewRequest]
Subject="CN=ИмяСертификата ,O=Организация, L=Город, S=Улица, C=Страна, E=Почта"
ProviderName="Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
ProviderType=80
KeySpec=1
Exportable = TRUE
KeyUsage=0xf0
MachineKeySet=true
RequestType=Cert
SMIME=FALSE
ValidityPeriod=Years
ValidityPeriodUnits=2
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

В целом с веб-сервером мы закончили, в default web site вы можете увидеть, что были автоматически созданы virtual directory и applications «CertSrv». При желании можно создать отдельную виртуальную директорию под CRL’ки.

Установка сетевого ответчика (Online responder)

А вот мы и вернулись к установке автоответчика.

1. Добавляем роль в «Диспетчере серверов» (Server Manager) — «Далее (Next)» 

1.1. Установка ролей и компонентов (Add roles and features wizard)» — «Далее (Next)»;

1.2. «Роли сервера (Server roles), раскрываем роль: Служба сертификатов Active Directory (Certificate Services Active Directory); и устанавливаем галочку на «Сетевой ответчик» (Online Responder) 

1.3. Завершаем работу с мастером ролей и компонентов, путём односмысленных нажатий «Далее (Next)».

В IIS была добавлена Applications: ocsp. Только не пугайтесь, что сама по себе директория пустая. Так и должно быть. 

Нам осталось настроить центр сертификации и выпустить сертификат на OCSP.

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

1. В «Диспетчере серверов (Server manager)» — выбираем «Служба сертификации Active Directory (AD CS) – правой клавишей по вашему серверу и открываем: «Центр сертификации (Certification Authority).

1.1. Вы попали в оснастку управления центром сертификации: certsrv.

1.2. Выбираем ваш центр сертификации и открываем свойства (рис. 10):

1.3. Следующим важным шагом выступает настройка точек распространения CDP и AIA.

Authority Information Access (AIA) — содержит ссылки на корневой сертификат центра сертификации (Certification Authority)

CRL Distribution Point — содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. (рис. 11)

Мы используем веб-сервер, который доступен как внутри сети, так и из интернета (так как сертификаты могут использоваться пользователями интернета) по одному и тому же URL.

1.4. В разделе свойства переходим в «Расширения (Extensions):

 Удаляем ненужные точки распространения и оставляем локальную и внешнюю ссылку для CDP:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<CaName><CRLNAmeSuffix><DeltaCRLAllowed>.crl

Ставим галочки «Включить в CRL. Включить в CDP (Include in CRL. Include in the CDP)».

AIA:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

Ставим галочку: «Включать в AIA- расширение выданных сертификатов (Include in the AIA extension of issued certificates)»

OCSP:

https://<ip_address/dns_name>/ocsp

Ставим галочку: «Включать в расширение протокола OCSP (Include in the online certificate status protocol (OCSP) extension)»

В свойствах центра сертификации можно настроить автоматический выпуск сертификатов при поступившем запросе. Так вы исключаете возможность проверки указанных требуемых полей сертификатов. Для этого перейдите в «Модуль политик (Policy Module)» — «Свойства (Properties)» и выберите соответствующий пункт:

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

Во втором случае из-за отсутствия шаблонов в Standalone CA сертификаты будут выпускаться автоматически. (рис. 12)

Да, центр сертификации уже функционирует и доступен по указанному dns-имени. Не забудьте открыть 80 и 443 порты для функционирования веб-сервера и online-reposnder’a, настройкой которого мы займёмся далее.

Проверить работу ЦС вы можете, перейдя в ChromiumGost или Internet Explorer или Edge (с поддержкой Internet Explorer(IE)): https://localhost/CertSrv.

При переходе по ссылке извне в IE необходимо добавить наш веб-сервер в «Надежные сайты (Trusted Sites)» в настройках в пункте «Безопасность».  Не забудьте, что должен быть установлен КриптоПро CSP, в ином случае при выпуске сертификата вам не будет доступен выбор ГОСТовского криптопровайдера (рис.13). 

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

Вернёмся в оснастку certsrv к нашему центру сертификации и настроим выпуск разностных CRL. Для этого необходимо открыть «Свойства (Properties)» раздела «отозванных сертификатов (Revoked Certificates)» (рис. 14).

1. Задаём «Интервал публикации CRL (CRL Publications interval)».

1.1. Включаем публикацию разностных CRL и задаём интервал.

Кажется, что все хорошо. Но есть один момент:

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

Выполните следующую команду в power shell:

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

Настройка OCSP — сетевого ответчика (Online responder)

Так как у Standalone центра сертификации нет шаблонов, нам необходимо вручную сформировать запрос и выпуск сертификата для конфигурации отзыва (Array configuration) в «Управление сетевым ответчиком (Online responder management). Для это используйте следующую конфигурацию для формирования запроса 

1.1. Создайте: ocsp.txt cо следующим внутренним содержанием:

[NewRequest]
Subject = "CN=Имя"
PrivateKeyArchive = FALSE
Exportable = TRUE
UserProtected = FALSE
MachineKeySet = TRUE
ProviderName = "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
KeyLength = 512
UseExistingKeySet = FALSE
RequestType = PKCS10
[ApplicationPolicyStatementExtension]
Policies = OCSPSigning
Critical = false
[OCSPSigning]
OID = 1.3.6.1.5.5.7.3.9
[EnhancedKeyUsageExtension]
OID="1.3.6.1.5.5.7.3.9"
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty

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

1.3. Узнаем, на какой срок сейчас выпускаются сертификаты. Для этого воспользуемся командой - certutil –getreg cavalidityperiodunits  

Результат — на рис. 15.

1.4. Изменим длительность выпуска сертификата:

 #Изменение выпуска сертификатов с текущего состояния на длительность в 5 лет
 certutil -setreg caValidityPeriodUnits 5 
 #Перезапуск сервера
 net stop certsvc 
 net start certsvc 

1.5. Сформируем запрос и выпустим сертификат для сетевого автоответчика (рис 16.):

#Конфигурирование запроса
 certreq -new <имя>.inf <имя>.req 
 
#Формирование запроса в ЦС
 certreq -submit <имя>.req
 
#Одобрение запроса (Можно руками через оснастку управления центром сертификации)
 certutil.exe -Resubmit "Цифра запроса" 

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

1.6. Экспортируем сертификат из центра сертификации и устанавливаем его в личные сертификаты локального компьютера.

1.6.1. После запроса сертификата открываем оснастку: Certificates (Run — MMC – Add or remove Snap-ins – Certificate),

1.6.2. Выбираем сертификат, выданный для сетевого ответчика. Нажимаем правой клавишей и открываем «Все задачи (Управление закрытыми ключами (All Tasks — Manage Private keys)». 

1.6.3. В открывшемся окне Permissions необходимо добавить в «Группы и пользователи (Group and Users):   Network Service и выдать право Read для этой учётной записи. (рис.16.1)

Это нужно сделать, так как служба OCSP работает от лица Network Service.

1.7. Далее переходим в настройки самого сетевого ответчика. (рис. 17)

1.8. Нам необходимо добавить «Конфигурацию отзыва (Revocation Configuration) – «Добавить»

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

2.1. «Далее».

2.2. Введите имя конфигурации – «Далее».

2.3. Выбираем второй пункт: «Выбрать сертификат в локальном хранилище сертификатов (Select a certificate from the local certificate store)» — «Далее».

2.4. В следующем окне нажимаем «Обзор (Browse)» и выбираем корневой сертификат нашего ЦА – «Больше вариантов (More choices)». (рис. 17) – «Далее».

2.5. В следующем окне выбираем «Выбрать сертификат подписи вручную (Manually a signing sertificate)

2.6. В последнем окне нажимаем «Поставщик (Provider)». Здесь необходимо указать источник, из которого будут браться базовые и разностные CRL. В нашем случае: http://localhost/CDP/CA-C4Y-VPN.crl (для базового) и  http://localhost/CDP/CA-C4Y-VPN+.crl (для разностного).

2.7. Осталось прицепить к нашей конфигурации выпускаемый ранее сертификат и проверить некоторые моменты.

2.7.1. Переходим в «Конфигурацию массива(array configuration)», выбираем конфигурацию и нажимаем «Назначить сертификат подписи (Assign Signing Certificate)». В появившемся окне нужно просто нажать «ОК».

2.7.2. Теперь необходимо «Обновить конфигурацию массива». Для этого выбираем «Конфигурация массива (Array configuration) – «Обновить (Refresh)»

2.7.3. После всех этих действий главное окно оснастки ocsp должно выглядеть так, как на рисунке 19.

В процессе самостоятельной настройки «сетевого ответчика» может возникнуть много вопросов, особенно если нет опыта работы с Standalone центром сертификации, в котором отсутствуют шаблоны, без которых можно обойтись, но пути становятся длиннее в исполнение.  Кстати говоря, если после прикрепления сертификата вы не получили заветное Working, то проверьте следующее (рис.20, 20.1):

Чтобы проверить работу центра сертификации и сетевого автоответчика, выпустите сертификат для конечного пользователя, установите его и экспортируйте в какую-нибудь директорию. А после воспользуйтесь утилитой: Certutil –url /patch/test.crt

Для подробного отчёта вы можете воспользоваться: certutil –verify –urlfetch /patch/test.crt

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

Дополнительно:

Что ещё интересного есть в блоге Cloud4Y

→ Малоизвестный компьютер SWTPC 6800

→ Сделайте Linux похожим на Windows 95

→ Бесплатные книги, полезные для IT-специалистов и DevOps

→ WD-40: средство, которое может почти всё

→ Игры для MS-DOS с открытым исходным кодом

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный материал является переводом оригинальной статьи «ATA Learning : Michael Soule : Manage Certs with Windows Certificate Manager and PowerShell».

Работа с сертификатами обычно является одной из тех дополнительных задач, которые вынужден брать на себя системный администратор Windows. Диспетчер Сертификатов Windows (Windows Certificate Manager) — это один из основных инструментов, который позволяет выполнять эту работу.

В этой статье мы рассмотрим работу с сертификатами применительно к операционной системе Windows. Если же вы хотите узнать больше о том, как работают сертификаты в целом, ознакомьтесь с сопутствующей статьей «Your Guide to X509 Certificates».

Понимание хранилищ сертификатов

В диспетчере сертификатов Windows все сертификаты находятся в логических хранилищах, называемых «хранилищами сертификатов». Хранилища сертификатов – это «корзины», в которых Windows хранит все сертификаты, которые в настоящее время установлены, и сертификат может находиться более чем в одном хранилище.

К сожалению, хранилища сертификатов — не самая интуитивно понятная концепция для работы. О том, как различать эти хранилища и как с ними работать, вы прочитаете ниже.

Каждое хранилище находится в Реестре Windows и в файловой системе. При работе с сертификатом в хранилище вы взаимодействуете с логическим хранилищем, не изменяя напрямую реестр или файловую систему. Этот более простой способ позволяет вам работать с одним объектом, в то время как Windows заботится о том, как представить этот объект на диске.

Иногда можно встретить хранилища сертификатов, называемые физическими или логическими хранилищами. Физические хранилища ссылаются на фактическую файловую систему или место в реестре, где хранятся разделы реестра и / или файл(ы). Логические хранилища — это динамические ссылки, которые ссылаются на одно или несколько физических хранилищ. С логическими хранилищами намного проще работать, чем с физическими хранилищами для наиболее распространенных случаев использования.

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

Сертификаты пользователей

Если вы хотите, чтобы сертификат использовался одним пользователем, то идеальным вариантом будет хранилище пользовательских сертификатов внутри Диспетчера сертификатов Windows. Это общий вариант использования процессов аутентификации на основе сертификатов, таких как проводной IEEE 802.1x.

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

Компьютерные сертификаты

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

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

Сертификаты компьютера находятся в кусте реестра локального компьютера и в подкаталогах ProgramData. Сертификаты пользователя находятся в кусте реестра текущего пользователя и в подкаталогах AppData. Ниже вы можете увидеть, где каждый тип хранилища находится в реестре и файловой системе.

Предварительные требования

В оставшейся части этой статьи вы найдете несколько примеров, демонстрирующих взаимодействие с хранилищами сертификатов Windows. Чтобы воспроизвести эти примеры, убедитесь, что выполняются следующие требования:

• Windows Vista, Windows Server 2008 или более новая операционная система. В показанных примерах используется Windows 10 Корпоративная версии 1903.
• Знакомство с PowerShell. Хотя это и не обязательно, этот язык будет использоваться для ссылки на сертификаты, где это необходимо. Все показанные примеры были созданы с помощью Windows PowerShell 5.1.
• Вам не потребуется устанавливать какие-либо специальные сертификаты, но использование самозаверяющего сертификата полезно.

Управление сертификатами в Windows

В Windows есть три основных способа управления сертификатами:

• Оснастка консоли управления Microsoft (MMC) сертификатов (certmgr.msc)
• PowerShell
• Инструмент командной строки certutil

В этой статье вы узнаете, как управлять сертификатами с помощью оснастки Certificates MMC и PowerShell. Если вы хотите узнать больше о том, как использовать certutil, ознакомьтесь с документацией Microsoft.

PowerShell против диспетчера сертификатов Windows

Поскольку в Windows можно управлять сертификатами несколькими способами, встаёт вопрос выбора, что лучше использовать — GUI (MMC) или командную строку с PowerShell.

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

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

Использование диспетчера сертификатов Windows (certmgr.msc)

Чтобы просмотреть сертификаты с помощью MMC, откройте Диспетчер сертификатов: откройте меню «Пуск» и введите certmgr.msc. Это вызовет Windows Certificates MMC. Это начальное представление предоставит обзор всех логических хранилищ, отображаемых в левом окне.

На снимке экрана ниже видно, что выбрано логическое хранилище доверенных корневых центров сертификации

Просмотр физических хранилищ

По умолчанию Диспетчер сертификатов Windows не отображает физические хранилища. Чтобы показать их, в верхнем меню оснастки выбирайте «View» > «Options«. Затем вы увидите варианты отображения физических хранилищ сертификатов. Включение этого параметра упрощает определение конкретных путей в Windows.

Теперь вы можете видеть, что дополнительные контейнеры показаны в примере логического хранилища доверенных корневых центров сертификации, показанном ранее. Сертификаты по-прежнему сгруппированы относительно их логических хранилищ, но теперь вы можете увидеть физическое хранилище «Реестр».

Проверка атрибутов в диспетчере сертификатов Windows

Есть много атрибутов сертификата, которые вы можете увидеть при просмотре их с помощью MMC. Например, вы, вероятно, захотите выбрать определенные сертификаты по их атрибутам. Самый простой способ сделать это — указать Serial Number сертификата или значение Thumbprint. Если сертификат был подписан центром сертификации (CA), при выдаче он будет иметь серийный номер. Thumbprint вычисляется каждый раз при просмотре сертификата.

Вы можете увидеть некоторые атрибуты сертификата, открыв его в MMC, как показано ниже.

Следует отметить одну важную особенность — встроенные закрытые ключи. Сертификаты в Windows также могут иметь соответствующий закрытый ключ. Эти закрытые ключи хранятся в соответствующих физических хранилищах в виде зашифрованных файлов.

Чтобы быстро отличать сертификаты с соответствующим закрытым ключом и без него, посмотрите на значок сертификата. В Диспетчере сертификатов Windows, если значок просто выглядит как лист бумаги с лентой, соответствующий закрытый ключ отсутствует. Если у сертификата есть закрытый ключ, вы увидите ключ на значке MMC, и ключ в нижней части вкладки «Общие» при открытии сертификата

Использование PowerShell по физическому хранилищу

Как и в случае с MMC, вы можете просматривать сертификаты и управлять ими с помощью PowerShell. Давайте сначала проверим сертификаты в их физических хранилищах (реестр и файловая система).

Используя PowerShell командлет Get-ChildItem, вы можете перечислить все ключи и значения внутри родительского пути в реестре. Приведенная ниже команда перечислит все сертификаты вошедшего в систему пользователя в логическом хранилище промежуточных центров сертификации.

Get-ChildItem -Path 'HKCU:SoftwareMicrosoftSystemCertificatesCACertificates'

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

Другое распространенное хранилище — это Personal store. Ваши сертификаты для этого хранилища находятся в файловой системе, а не в реестре. В следующих командах мы покажем эти различные физические пути и их цели.

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

Get-ChildItem -Path $env:APPDATAMicrosoftSystemCertificatesMyCertificates

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

Get-ChildItem -Path $env:APPDATAMicrosoftSystemCertificatesMyKeys

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

Get-ChildItem -Path $env:APPDATAMicrosoftCryptoKeys

Использование PowerShell по логическому хранилищу

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

PowerShell может получить доступ к логическим хранилищам Windows с помощью PSDrive-объекта «Cert:«, который сопоставляет сертификаты с физическими хранилищами так же, как это делает MMC.

К сожалению, MMC и «Cert:» не маркируют логические хранилища одинаково. Ниже вы можете увидеть сравнительную таблицу общих хранилищ и их названий как в MMC, так и в «Cert:» PSDrive.

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

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

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

Get-ChildItem -Path 'Cert:CurrentUserRoot'

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

Общие расширения уже доступны как свойства объектов сертификата. В приведенном ниже примере вы используете Get-Member для вывода списка всех свойств возвращаемых объектов.

Get-ChildItem -Path 'Cert:CurrentUserRoot' | Get-Member -MemberType Properties

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

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

Покажем пример взаимодействия с свойствами типа ScriptProperty. В приведенной ниже команде вы извлекаете Key Usages.

((Get-ChildItem -Path 'Cert:CurrentUserRoot' | Select -First 1).Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Key Usage'}).format($true)

Новая часть, которую мы вводим в приведенной выше команде, — это метод форматирования, который выполняет декодирование ASN.1. Вы передаете ему логическое значение (например, $true), чтобы определить, хотим ли мы, чтобы возвращаемый объект был однострочным или многострочным.

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

$thumb = "cdd4eeae6000ac7f40c3802c171e30148030c072"
Get-ChildItem -Path 'Cert:CurrentUserRoot' | Where-Object {$_.Thumbprint -eq $thumb}

Создание самозаверяющих (self-signed) сертификатов с помощью PowerShell

PowerShell может создавать самозаверяющие (self-signed) сертификаты с помощью командлета New-SelfSignedCertificate. Самозаверяющие сертификаты полезны для тестирования, поскольку они позволяют генерировать пару открытого и закрытого ключей без использования центра сертификации.

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

В приведенном ниже примере PowerShell создает пару открытого и закрытого ключей, самозаверяющий сертификат и устанавливает их все в соответствующие хранилища сертификатов.

New-SelfSignedCertificate -Subject 'User-Test' -CertStoreLocation 'Cert:CurrentUserMy'
New-SelfSignedCertificate -Subject 'Computer-Test' -CertStoreLocation 'Cert:LocalMachineMy'

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

Импорт и экспорт сертификатов в MMC

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

Оба они требуют способов хранения этих криптографических объектов в стандартных форматах. Экспорт предоставляет функции для сохранения этих объектов и обеспечения использования широко распространенных стандартных форматов файлов. Импорт позволяет вам переносить криптографические объекты в операционные системы Windows.

Экспорт сертификатов из MMC относительно прост. Чтобы экспортировать сертификат без закрытого ключа, щелкните сертификат в MMC, выберите меню «Все задачи», а затем «Экспорт».

Во время экспорта вам будет предложено указать формат файла, как показано ниже. Наиболее распространены варианты кодирования — DER или Base-64

Экспорт закрытых ключей

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

• Вошедшая в систему учетная запись должна иметь разрешение на закрытый ключ (только для сертификатов компьютеров);
• Закрытый ключ должен быть помечен как экспортируемый.

Чтобы проверить разрешения для закрытых ключей локального компьютера, вы можете выбрать сертификат с закрытым ключом, выбрать «Все задачи» и «Управление закрытыми ключами» в MMC «Сертификаты». В открывшемся диалоговом окне отображаются записи управления доступом для закрытых ключей.

Когда выше обозначенные условия выполнены, вы можете выбрать сертификат, щелкнуть «Все задачи», а затем «Экспорт», как если бы вы использовали сертификат только с открытым ключом. При экспорте теперь у вас должна присутствовать возможность выбора экспорта закрытого ключа («Yes, export the private key»), как показано ниже.

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

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

Импорт сертификатов

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

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

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

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

Импорт и экспорт сертификатов в PowerShell

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

$certificate = Get-Item (Get-ChildItem -Path 'Cert:CurrentUserMy' | Where-Object {$_.Subject -eq $_.Issuer}).PSPath

Теперь, когда вы выбрали сертификат, вы можете использовать команду Export-Certificate, чтобы сохранить файл в кодировке DER, используя команду ниже.

Export-Certificate -FilePath $env:USERPROFILEDesktopcertificate.cer -Cert $certificate

Теперь давайте посмотрим на экспорт закрытого ключа. Ниже вы проверяете, что у выбранного сертификата есть закрытый ключ. Если он не возвращает True, то команда Get-Item, скорее всего, выбрала неправильный сертификат.

$certificate.HasPrivateKey

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

$pfxPassword = "ComplexPassword!" | ConvertTo-SecureString -AsPlainText -Force
Export-PfxCertificate -FilePath $env:USERPROFILEDesktopcertificate.pfx -Password $pfxPassword -Cert $certificate

В случае, если необходимо выполнить импорт, как и при экспорте, есть две команды. Одна команда для импорта сертификатов и одна для импорта файлов PFX.

Ниже команда Import-Certificate импортирует файл в формате DER, который вы экспортировали ранее, в личное хранилище текущего пользователя.

Import-Certificate -FilePath $env:USERPROFILEDesktopcertificate.cer -CertStoreLocation 'Cert:CurrentUserMy'

Допустим, вы тоже хотите установить закрытый ключ этого сертификата.

$pfxPassword = "ComplexPassword!" | ConvertTo-SecureString -AsPlainText -Force
Import-PfxCertificate -Exportable -Password $pfxPassword -CertStoreLocation 'Cert:CurrentUserMy' -FilePath $env:USERPROFILEDesktopcertificate.pfx

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

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

Удаление сертификатов с помощью PowerShell

При удалении сертификатов помните, что понятие «Корзина Windows» в этом случае отсутствует. Как только вы удалите сертификат, он исчезнет! Это означает, что очень важно подтвердить, что вы удаляете правильный сертификат, путем проверки уникального идентификатора, такого как серийный номер или значение расширения Thumbprint.

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

$certificate = Get-Item (Get-ChildItem -Path 'Cert:CurrentUserMy' | Where-Object {$_.Subject -eq $_.Issuer}).PSPath

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

$certificate.Thumbprint
$certificate.SerialNumber
$certificate.Subject

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

Приведенная ниже команда удаляет все выбранные объекты сертификата, используйте с осторожностью! Передав объект $certificate через конвейер в командлет Remove-Item в приведенной ниже команде, вы удалите все содержимое сертификата без каких-либо запросов на проверку.

$certificate | Remove-Item

Резюме

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