Инфраструктура открытых ключей в windows server 2016 часть 2

Рубрика: Администрирование /  ИТ-инфраструктура

Facebook Twitter Мой мир Вконтакте Одноклассники Google+

 СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, MCSE, MCSE:S, MCSE:M, MCITP EA, MCITP EMA, HP AIS, msv121@mail.ru

 ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, shapiro_leonid@yahoo.com

Инфраструктура открытых ключей
в Windows Server 2016. Часть 2. RootCA

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

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

Процедура самой установки службы сертификатов не отличается от установки любой другой роли Windows Server 2016 и знакома системному администратору. Добавляется новая роль – Active Directory Certificate Service. Перед установкой следует разместить файл capolicy.inf [1], содержимое которого мы обсуждали в предыдущей статье [3], в папке systemroot (см. рис. 1).

Рисунок 1. Сохранение файла capolicy.inf

Это позволит нам выполнить начальную конфигурацию сервера сертификатов. В процессе установки сервиса, вернее будет сказать после установочной настройки (см. рис. 2), потребуется задать учетную запись, от имени которой будет работать служба, тип развертывания – Stand Alone CA, роль удостоверяющего центра – RootCA.

Рисунок 2. Завершение процесса настройки сервера сертификатов

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

Рисунок 3. Значение AIA по умолчанию

Рисунок 4. Значения CDP по умолчанию

AIA расшифровывается как Au-thority Information Access и определяет место хранения актуальных сертификатов нашего сервера. CDP дает нам возможность определить место хранения списков отзывов, подписанных нашим сервером сертификатов. Оба эти расширения содержатся во всех выданных удостоверяющим центром сертификатах и, соответственно, должны быть доступны всем потребителям.

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

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

Изменение этих настроек может быть выполнено разными способами. Могут быть использованы графический интерфейс (GUI), утилита certutil [4], с помощью которой можно полностью выполнять любые задачи из командной строки, наконец, воспользоваться командлетами powershell.

Certutil.exe – программа командной строки, которая устанавливается как часть служб сертификации. Используется для сбора информации о конфигурации удостоверяющего центра, настройки служб сервиса, резервного копирования и восстановления компонентов ЦС и проверки сертификатов, пар ключей и цепочек сертификатов.

Администратор может вносить изменения в AIA и CDP-расширения, однако на уже выданные сертификаты это никак не повлияет, они содержат предыдущие значения, соответственно, надо учитывать этот факт и не лишать обладателей ранее выданных сертификатов возможности работы. Порядок строк в CDP определяет последовательность проверки списка отзыва сертификатов. Получается, что при наличии внешних клиентов надо учесть, что проверка, скажем, LDAP-пути, который поумолчанию стоит раньше в списке, будет для них просто невозможна. То есть станут возникать задержки [5], пока получится добраться до «рабочего» варианта. В этой ситуации целесообразно первым разместить HTTP-путь. Это же будет относиться и к не Windows-клиентам, которые не станут использовать LDAP для поиска сертификатов и списков отзыва.

Администратор может вносить изменения в AIA и CDP-расширения, однако это никак не повлияет на уже выданные сертификаты, они содержат предыдущие значения

Вообще наиболее часто используемым будет именно HTTP-вариант, поскольку он универсален и подходит любому клиенту независимо от его членства в домене AD DS и типа.

Стоит отметить, что у нас нет возможности частичной корректировки уже внесенной строки. Также невозможно изменить порядок следования строк. И поскольку указанный по умолчанию вариант в большинстве случаев не подходит, то ничего не остается, как только удалить эти строки полностью и внести новые значения, соответствующие требованиям. На этом этапе должны быть уже определены места хранения сертификатов и списков отзыва и подготовлен веб-сервер, что уже обсуждалось в предыдущей статье [3].

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

Для настройки параметров CDP будем применять утилиту certutil и воспользуемся следующей командой:

CertUtil [Options] -setreg

[{ca|restore|policy|exit|template|enroll|chain|PolicyServers}[ProgId]] RegistryValueName Value+ []

с помощью, которой и назначим точки публикации CRL.

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

Список отзыва сертификатов публикуется на самом сервере сертификатов в виде обычного файла с расширением CRL. Стало быть, надо указать папку, где будет этот файл храниться. Например, тот вариант, который предлагается по умолчанию: C:Windowssystem32CertSrvCertEnroll.

Он нам вполне подойдет. Следует понимать, что клиенты его получить не смогут, поскольку наш корневой сервер сертификатов для них недоступен. RootCA отключен от сети, да и вообще выключен. Значит, файл его списка отзыва должен храниться где-то еще. То есть на сервере распространения – это наш веб-сервер, который мы раньше установили. Нам придется его туда скопировать. Мы вернемся к вопросу переноса данных чуть позже в следующих статьях этого цикла.

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

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

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

Значит, список отзыва RootCA должен быть включен в выданные им сертификаты.

Какие пути надо включить? Первым будет HTTP, а вторым – LDAP-путь для клиентов AD. Вероятнее всего, до проверки LDAP дело не дойдет, но мы все-таки дополнительно внесем и этот путь.

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

certutil -setreg CACRLPublicationURLs

"1:C:Windows system32CertSrvCertEnroll%3%8.crln2:http://pki.nwtraders.msft/PKI/%3%8.crln10:

ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

Сам сертификат УЦ тоже должен где-то храниться, мы используем путь по умолчанию: C:Windowssystem32CertSrvCertEnroll.

Теперь то, что касается проверки цепочки доверия сертификатов. Клиенты будут проверять сами сертификаты, то есть надо включить информацию об их месте нахождения. Точно так же мы воспользуемся http и ldap-путями.

Настройку AIA выполним таким образом:

certutil -setreg CACACertPublicationURLs

"1:C:Windowssystem32CertSrvCertEnroll%3%4.crtn2:http://pki.nwtraders.msft/PKI//%3%4.crtn2:

ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

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

certutil -setreg CAValidityPeriodUnits 20

certutil -setreg CAValidityPeriod "Years"

certutil -setreg CACRLPeriodUnits 26

certutil -setreg CACRLPeriod "Weeks"

certutil -setreg CACRLOverlapUnits 2

certutil -setreg CACRLOverlapPeriod "Weeks"

certutil -setreg CACRLDeltaPeriodUnits 0

certutil -setreg CACRLDeltaPeriod "Hours"

Последовательно здесь настраиваются:

• Период действия сертификата центра сертификации
• Единицы измерения для ValidityPeriodUnits
• Периодичность выпуска списков CRL и Delta CRL, а также срок продленного действия списков CRL

Последнее, что осталось нам сделать, – настроить необходимый аудит.

certutil -setreg CAAuditFilter 127

Наконец, для определения значения переменной %6 -<ConfigurationContainer> выполните следующую команду:

certutil -setreg caDSConfigDN "CN=Configuration,DC=nwtraders,DC= msft"

Вот теперь мы можем считать, что корневой центр сертификации развернут.

Продолжение следует.

1. How CA Certificates Work. Overview of Capolicy.inf – https://technet.microsoft.com/en-us/library/cc737264(WS.10).aspx.
2. Prepare the Capolicy.inf – https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file.
3. Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительный этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.
4. Certutil – https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil.
5. Certification Authority Guidance – https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11).

Ключевые слова: инфраструктура открытых ключей, сертификаты, сервер сертификатов, конфигурация.

Установка центра сертификации на предприятии. Часть 2 +19

Информационная безопасность, Системное администрирование, Серверное администрирование, Блог компании Microsoft, IT-инфраструктура

---

Рекомендация: подборка платных и бесплатных курсов системных администраторов — https://katalog-kursov.ru/

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

Введение

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

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

• 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) — документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.

Общие вопросы планирования

Для успешного внедрения любого технического решения необходимо тщательное планирование. Внедрение PKI не является исключением. Более того, если в определённых случаях ошибки изначального планирования могут быть исправлены относительно быстро и легко, то в PKI это однозначно не так. Как я уже отмечал, службы PKI рассчитаны на работу на протяжении многих лет с минимальными (или некритичными) изменениями в ходе работы.

Например, срок действия сертификатов CA составляет порядка 10-20 лет. Одна из причин такого долгого срока жизни в том, что перевыпуск этих сертификатов является несколько трудоёмкой операцией и могут потребовать изменений на большом количестве клиентов. Усугубляется это тем, что изменения потребуются и на клиентах, к которым вы можете не иметь доступа. Другой момент заключается в том, что при внесении некоторых изменений в архитектуру PKI вам потребуется поддерживать текущую конфигурацию на всё время жизни уже изданных сертификатов. Иными словами, для новых сертификатов будет действовать новая конфигурация, но параллельно с ней необходимо будет поддерживать и предыдущую конфигурацию, чтобы уже изданные сертификаты могли корректно работать. Это тоже добавляет сложности в поддержке PKI в работоспособном состоянии.

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

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

Построение диаграммы PKI

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

На диаграмме представлены следующие компоненты и их логические связи:

• Корневой ЦС — выдаёт сертификат только подчинённому ЦС и публикует свой сертификат и списки отзыва на сервер отзыва (Revocation Server);
• Подчинённый (промежуточный) ЦС — выдаёт сертификаты конечным потребителям и публикует свой сертификат и списки отзыва на сервер отзыва. При этом сам скачивает список отзыва корневого ЦС с сервера отзыва;
• Сервер отзыва — является хранилищем сертификатов ЦС и их списков отзыва, которые может скачать любой клиент;
• Клиентские подключения — получают свои сертификаты у подчинённого ЦС и скачивают списки отзыва с сервера отзыва.

Физическая топология будет несколько отличаться и иметь следующий вид:

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

Планирование имён ЦС

Имя ЦС – это имя, которое будет отображено в поле Subject конкретного ЦС. Не путать с именем хоста, на котором работает служба сертификатов. Полное имя ЦС будет состоять из двух компонентов, самого имени (атрибут CN или Common Name) и опционального суффикса в формате X.500. По умолчанию ADCS назначает имя в следующем формате:

Для Standalone CA: <ComputerName>-CA

Для Enterprise CA: <DomainShortName>-<ComputerName>-CA, <X500DomainSuffix>

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

• Имя должно отражать название организации (можно и сокращённое) и роль конкретного ЦС в иерархии (атрибут CN, Common Name);
• Суффикс должен отражать название отдела или подразделения, которое отвечает за его управление в атрибуте OU (Organizational Unit);
• Дублировать полное название организации (атрибут O, Organization);
• Юридическое место дислокации ЦС. Для этого достаточно использовать атрибуты L (Locality) и C (Country). Как правило, это название города и страны, где юридически зарегистрирована организация. Если необходимо, можно указать штат/область посредством атрибута S (State).

Предположим, что вы подбираете имя для корневого ЦС компании Contoso Pharmaceuticals Ltd., которая находите в городе Рига, Латвия и управление обеспечивается отделом информационных технологий. В этом случае имя ЦС может иметь следующий вид:

CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LV

Следует помнить, что атрибут Country поддерживает только двухбуквенный индекс страны. Например, LV, GB, RU, US и т.д. В качестве дополнительных примеров, можете обратиться к сертификатам ЦС коммерческих провайдеров, как VeriSign/Symantec, DigiCert и т.д. Для подчинённого ЦС это имя будет похожим, за исключением того, что слово Root в имени будет заменено на Subordinate или Issuing. В случае трёхуровневой иерархии, где явно выделяется ЦС политик, слово Root будет заменено на Policy. Как я выше отмечал, в вашей компании могут применяться другие правила, и вы можете их внедрить в имена ЦС, на функциональность это влиять не будет. При этом следует избегать:

• Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола [MS-WCCE]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
• Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, a, z, U, ?). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

Планирование списков отзыва (CRL)

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

1. Точки публикации и распространения списков отзыва;
2. Состав и срок действия списков отзыва.

Точки публикации и распространения списков отзыва

Для публикации списков отзыва используются два типа точек распространения CRL: точка публикации (куда физический файл будет записываться) и точка распространения (получения) файла.

Первый тип точек указывает локальный или сетевой путь (в формате UNC) куда будет записываться файл. Второй тип точек будет регистрироваться в издаваемых сертификатах с указанием пути, по которому клиенты могут скачать список отзыва. Эти пути публикуются в расширении сертификата CRL Distribution Points. Эти пути в общем случае не будут совпадать (кроме протокола LDAP, где пути публикации и распространения совпадают). При определении точек публикации следует руководствоваться следующими правилами:

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

Более детально о планировании расширений CRL Distribution Points и Authority Information Access и практиками вы можете ознакомиться в статье моего блога: Designing CRL Distribution Points and Authority Information Access locations.

Состав списков отзыва

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

Даже при наличии высокоскоростных подключений трафик списков отзыва будет существенным по размеру, т.к. все потребители сертификатов нуждаются в актуальной версии списка отзыва.
Для уменьшения трафика списков отзыва предусматривают публикацию двух типов CRL: базовый (Base CRL) и дифференциальные (Delta CRL). Базовый список включает полный список отзыва. Дифференциальный список включает в себя только список отозванных сертификатов, которые были отозваны с момента последней публикации базового CRL. Это позволяет вам публиковать базовый список реже и на более длительный срок, а для ускорения времени реакции клиентов на отозванные сертификаты в промежутке выпускать несколько короткоживущих дифференциальных CRL.

Подбор параметров зависит от несколько факторов. Например, планируемый объём издаваемых сертификатов и планируемый объём отзыва. Рассмотрим типовые сценарии.

Корневой ЦС

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

Справка: как посчитать планируемый размер файла CRL исходя из объёмов отзыва? Типичный пустой CRL занимает примерно 600-800 байт. Каждая запись об отозванном сертификате занимает 88 байт. Исходя из этих значений можно высчитать размер CRL в зависимости от количества отозванных сертификатов.

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

Издающий ЦС

Для издающего ЦС картина меняется. Объём издаваемых сертификатов уже высок, он может составлять тысячи и миллионы штук. Потребителями являются пользователи и устройства, которые обладают высоким риском отзыва, поскольку они не находятся под постоянным контролем квалифицированного персонала, и невозможно обеспечить надлежащие меры. Как следствие, список отзыва может достигать серьёзных размеров. Например, если заложить 10% риск отзыва, то на миллион изданных сертификатов приходится порядка 100к отозванных. 100к записей по 88 байт будет составлять немногим меньше 10мб. Очень часто обновлять файл на 10мб не очень практично, целесообразней его публиковать реже, а в интервале между публикациями основного CRL распространять несколько облегчённых дифференциальных Delta CRL. Т.е. если для корневого ЦС достаточно только базового списка отзыва, то для ЦС, выпускающих сертификаты конечным потребителям, следует применять и дельты.

Планирование сроков действия CRL

Это всё было о составе списков отзыва для каждого ЦС. Теперь следует определить сроки:

• На какой срок следует публиковать список отзыва?
• Как долго информация в нём может считаться достоверной и достаточно актуальной?

Здесь тоже можно применить подход в зависимости от условий эксплуатации. Риск отзыва промежуточного ЦС весьма низкий, следовательно, нет смысла слишком часто публиковать пустой CRL. В современной практике применяются следующие типовые значения по сроку действия CRL для ЦС, которые выписывают сертификаты только другим ЦС: 3, 6 или 12 месяцев. Здесь следует отталкиваться от степени риска и административных расходов на обслуживание списков отзыва. Если нет никаких особых условий, то я рекомендую выбирать что-то среднее, порядка 6 месяцев.

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

Можно понять желание администраторов уменьшить это время (в идеале – мгновенно), чтобы клиенты не признавали отозванный сертификат действительным. Однако, уменьшение одного риска приводит к увеличению другого риска. Представьте, что по какой-то причине отказал сервер ЦС в момент, когда предыдущий CRL близок к истечению срока действия, а новый CRL невозможно опубликовать. Тогда начнутся проблемы с проверкой отзыва сертификатов и их остановке, пока сервер ЦС не будет восстановлен в работе. Этот момент необходимо обязательно учитывать при настройке сроков действия списков отзыва.

Microsoft CA по умолчанию уже закладывает некоторый резерв по времени на непредвиденные случаи и когда распространение списков отзыва по всем точкам публикации занимает некоторое время (например, вызваны латентностью репликации). Этот резерв в английской терминологии называется CRL overlap. Идея защитного механизма заключается в том, что ЦС генерирует и публикует списки отзыва до истечения действия предыдущего опубликованного списка.

Это достигается использованием двух полей в списке отзыва: Next CRL Publish и Next Update. Поле Next CRL Publish указывает на время, когда ЦС опубликует обновлённый список отзыва (автоматически). Next Update указывает на время, когда срок действия текущего списка истечёт. Поле Next Update будет всегда выставлен на несколько позднее время, чем Next CRL Publish. Другими словами, ЦС опубликует обновлённый список отзыва до истечения срока предыдущего. Алгоритм вычисления автоматических значений для этих полей нетривиален и описан в следующей статье: How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). Если значения по умолчанию вас не устраивают по тем или иным причинам, их можно отредактировать. Необходимо учитывать, что запас по времени имеет нижние и верхние границы. Например, верхняя граница не может превышать срока действия самого CRL. Так, если срок действия CRL составляет 1 день, то запас может составлять максимум 1 день, и тогда ЦС будет публиковать списки отзыва ежедневно, но срок действия будет составлять 2 дня. Тем самым достигается запас времени на восстановление ЦС в случае непредвиденных обстоятельств.

На практике я достаточно часто наблюдал желание администраторов закрутить настройки сроков действия CRL до минимального предела с таким обоснованием: «пользователь уволился и не должен иметь возможность аутентифицироваться с отозванным сертификатом». Мотивация понятна, но решение задачи через списки отзыва не совсем правильно. В случае, если пользователю необходимо прекратить доступ к корпоративным системам, необходимо отключить учётную запись пользователя или компьютера.

При планировании сроков действия CRL и периодичности следует руководствоваться следующими рекомендациями:

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

Online Certificate Status Protocol

В рамках данного цикла статей я не буду использовать OCSP серверы для дополнительного метода распространения информации об отозванных сертификатах. При желании вы можете обратиться к исчерпывающей статье на сайте TechNet: Online Responder Installation, Configuration, and Troubleshooting Guide. Как показывает практика, в большинстве случаев установка и поддержка OCSP не оправдывает себя по ряду причин.

Основная задача OCSP: разгрузка трафика скачивания CRL. Как известно, CRL содержит список всех отозванных сертификатов за всё время жизни ЦС, и в какой-то момент при интенсивном отзыве сертификатов его размер может достичь внушительных размеров (несколько мегабайт). Выше уже отмечалось, что 100к отозванных сертификатов составит порядка 9МБ в CRL файле. В то время как проверка отзыва любого сертификата при использовании OCSP будет занимать фиксированный размер ~2.5КБ. Есть ощутимая разница. На практике же, зачастую интенсивность отзыва гораздо ниже. Если говорить о корневых ЦС или ЦС политик, у них отзыв будет штучный, и размер их списка отзыва едва ли превысит 1КБ.

Следует отметить, что OCSP может быть эффективным в ситуации, когда есть один проверяемый сертификат и много клиентов, которые его хотят проверить. Это типичный сценарий сертификата SSL/TLS. В этом случае каждый клиент вместо скачивания условного 9МБ списка отзыва потратит 2.5КБ трафика OCSP. Но в обратной ситуации (один сервер проверяет множество клиентских сертификатов) OCSP может вызвать значительную нагрузку на сеть. К этому можно отнести типичные сценарии корпоративных сетей: аутентификация клиентов при помощи сертификатов, такие как аутентификация EAP-TLS в беспроводных сетях и VPN, аутентификация Kerberos на контроллерах домена. Предположим, сотрудники пришли на работу и используют сертификаты для аутентификации в сети (смарт-карты, сертификаты на мобильных устройствах) и контроллер домена, Серверы RADIUS вынуждены проверять каждый клиентский сертификат. Для проверки только 1К сертификатов будет затрачено 2.5МБ трафика. В этой ситуации пользы от OCSP никакой, даже наоборот.

Этот аспект учтен в логике продуктов Microsoft. Если за определённый промежуток времени клиент Crypto API проверяет 50 (это значение можно настроить) сертификатов от одного издателя при помощи OCSP, тогда на этом работа с OCSP заканчивается, и клиент скачивает и кэширует CRL для этого издателя. Более подробно с этим поведением можно ознакомиться в разделе Optimizing the Revocation Experience документа Certificate Revocation Checking in Windows Vista and Windows Server 2008.

Планирование политик выдачи сертификатов

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

Определение политик

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

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

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

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

Вот эти различия в процедурах и являются политиками выдачи, и эти политики должны регистрироваться в сертификатах. Конечные приложения могут использовать политики выдачи для определения доступа к ресурсу. Наиболее известными примерами таких приложений являются Network Policy Server (NPS) и Active Directory Dynamic Access Control. Например, все сотрудники компании могут подключаться при помощи сертификатов к общей беспроводной сети компании. Но могут быть беспроводные сети, доступ к которым будет разрешён только при использовании сертификатов на смарт-картах.

В NPS можно настроить правило, что будет приниматься не просто сертификат входа, а тот, который был выдан в соответствии с политикой выдачи сертификатов для смарт-карт. Поскольку эта информация отражена в сертификате, NPS может различить два похожих сертификата (оба для аутентификации пользователя) по политикам выдачи. Если сертификат не содержит свидетельств, что он был выдан в соответствии с указанной политикой выдачи, то доступ к сети не будет разрешён. Похожий принцип заложен и в Active Directory Dynamic Access Control, где можно указать критерии для различных уровней доступа.

Описание политик

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

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

Второй ответ вытекает из первого: описание политик выдачи сертификатов в конечном итоге станет документацией на всю PKI и будет иметь своё фирменное название – Certificate Practice Statement или CPS (к сожалению, не нашёл подходящего термина на русском языке, поэтому буду использовать англоязычную аббревиатуру). Для унификации описания политик выдачи существует рекомендованный (но не обязательный) шаблон, описанный в RFC 3647. По сути, этот документ является фреймворком по написанию политик и освещает всевозможные аспекты работы PKI. Совершенно не обязательно описывать все имеющиеся разделы в документе. Можно документировать только то, что применимо к вашей ситуации, или добавлять что-то своё.

В общем случае CPS будет состоять из двух частей:

1. Описание иерархий PKI, общих для всех процедур и положений, которые будут общими для всех конкретных политик выдачи.
2. Описание положения специфичные для конкретной политики выдачи. В зависимости от размерности PKI, её особенностей, на каждую политику может составляться отдельный CPS, но чаще всего это сводится к составлению единого документа, который будет описывать всё.

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

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

Идентификаторы политик должны быть представлены в формате ITU-T и ISO. В своё время я написал небольшую вводную статью про объектные идентификаторы: Что в OID’е тебе моём? В ней есть информация о том, как получить в IANA (Internet Assigned Numbers Authority) свою ветку идентификаторов. Получив свою ветку, вы внутри неё выделяете подмножество идентификаторов для политик выдачи, например: 1.3.6.1.4.1.x.1, где x – уникальный идентификатор компании, зарегистрированный в IANA. И в нём вы регистрируете конкретные политики выдачи:

• 1.3.6.1.4.1.x.1.1
• 1.3.6.1.4.1.x.1.2
• 1.3.6.1.4.1.x.1.3
• 1.3.6.1.4.1.x.1.4
• …

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

Например, на картинке показан сертификат DigiCert, выданный в соответствии с политикой выдачи под идентификатором 2.16.840.1.114412.2.1 (в данном случае это Extended Validation) и 2.23.140.1.1 (указывает, что ЦС выпускает сертификаты согласно правилами CAB/Forum) и с ссылкой на CPS. По этой ссылке можно скачать самую последнюю версию их CPS и ознакомиться с условиями получения и использования сертификатов.

Когда все политики определены, им присвоены идентификаторы и определены указатели, эта информация помещается в конфигурационный файл установки ЦС, чтобы эти сведения попали в сертификат. Для включения информации о политиках выдачи конечных сертификатов следует настроить шаблоны сертификатов и для каждого шаблона указать конкретные политики выдачи. Причём, если какая-то политика включена в конечный сертификат, её идентификатор должен быть представлен как в самом конечном сертификате, так и во всех промежуточных сертификатах цепочки (кроме корневого ЦС). Более подробно об этом можно прочесть в статьях моего блога: Certificate Policies extension – all you should know (part 1) и Certificate Policies extension – all you should know (part 2). Эти статьи освещают общие вопросы, связанные с политиками выдачи, правилами их проверки в цепочках сертификатов и способы их включения в сертификаты на платформе Windows.

Здесь есть один тонкий момент: сертификат ЦС выдаётся на довольно большой срок (10 лет и более) и при добавлении или удалении политик выдачи на конкретном ЦС необходимо перевыпускать сертификат самого ЦС, что усложняет процесс управления ЦС и увеличивает административные расходы. Не существует способа описать группу политик одним идентификатором (например, идентификатором компании), поскольку маски не поддерживаются. В RFC 5280 §4.2.1.4 предусмотрен глобальный идентификатор (global wildcard) anyPolicy = 2.5.29.32.0, который покрывает любые политики выдачи.

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

Планирование аппаратных требований

Службы сертификатов AD CS в целом нетребовательны к аппаратным ресурсам (на фоне других серверных служб). Основная нагрузка ложится на центральный процессор для выполнения криптографических операций (хэширование, шифрование и подпись). Кроме того, есть определённая нагрузка на диски для работы базы данных сертификатов (AD CS использует JET Database Engine). Это в теории.

На практике аппаратных ресурсов даже бюджетных линеек серверов будет более чем достаточно для функционирования служб сертификатов, поскольку реальные потребности весьма малы на фоне требований ОС к аппаратным ресурсам. В эпоху Windows Server 2003 была написана статья Evaluating CA Capacity, Performance, and Scalability (ссылка на архивную копию, т.к. оригинал удалён с сайта TechNet), освещающую общие моменты, которые нужно учитывать при планировании аппаратных ресурсов. Статья несколько устарела (например, лимит количества выдаваемых сертификатов в разрезе БД значительно увеличен), но общие характеристики мало изменились.

В 2010 году, Windows PKI Team провела тесты производительности с использованием более современного оборудования (образца 2007 года) под управлением Windows Server 2008. С результатами можно ознакомиться в их блоге: Windows CA Performance Numbers. Данные в этих статьях, говорят о том, что сервер AD CS на аппаратном сервере выпуска 2007 года позволяет выпускать порядка 150 сертификатов в секунду. Реальная же потребность в скорости выдачи сертификатов на порядки ниже. Поэтому для ЦС общего назначения советую ориентироваться на рекомендуемые аппаратные требования к самой ОС. Это касается как корневого, так и издающих ЦС. Поэтому перечислю здесь требования для Windows Server 2016 (Windows Server 2016 System Requirements):

• CPU — dual-core 1.4 GHz;
• Память — 1GB RAM;
• Диск — 48 GB для системного диска и не менее 48 GB для локальных резервных копий. Системный раздел желательно разместить на дисках с RAID1.
• Дисплей — SVGA (800*600);
• Сеть — стандартный сетевой интерфейс.

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

Итоговая конфигурация

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

Корневой ЦС

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

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	Standalone CA
Тип ЦС	Root CA
Срок действия издаваемых сертификатов	15 лет
Публикация в AD (контейнеры)	Certification Authorities AIA
Точки публикации CRT	1) По-умолчанию 2) C:CertDatacontoso-rca<CertificateName>.crt 3) IIS:InetPubPKIdatacontoso-rca<CertificateName>.crt*
Точки распространения CRT	1) URL=http://cdp.contoso.com/pki/contoso-rca<CertificateName>.crt
Точки публикации CRL	1) По-умолчанию 2) C:CertDatacontoso-rca<CRLNameSuffix>.crt 3) IIS:InetPubPKIdatacontoso-rca<CRLNameSuffix>.crt*
Точки распространения CRL	1) URL=http://cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt
Сертификат
Имя сертификата	Contoso Lab Root Certification authority
Дополнительный суффикс	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа	RSA#Microsoft Software Key Storage Provider
Длина ключа	4096 бит
Алгоритм подписи	SHA256
Срок действия	15 лет
Состав CRL	Base CRL
Base CRL
Тип	Base CRL
Срок действия	6 месяцев
Расширение срока действия	1 месяц
Алгоритм подписи	SHA256
Публикация в AD	Нет

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

Издающий ЦС

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

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

Сервер IIS

Название параметра	Значение параметра
Сервер ЦС
Веб-сайт	cdp
Заголовок хоста	cdp.contoso.com
Виртуальные директории	PKI=C:InetPubwwwrootPKIdata
Double Escaping	Включен

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

Об авторе

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

Установка центра сертификации Install the Certification Authority

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

Эту процедуру можно использовать для установки служб сертификатов Active Directory (AD CS), чтобы можно было зарегистрировать сертификат сервера на серверах, на которых выполняется сервер политики сети (NPS), служба маршрутизации и удаленного доступа (RRAS) или оба. You can use this procedure to install Active Directory Certificate Services (AD CS) so that you can enroll a server certificate to servers that are running Network Policy Server (NPS), Routing and Remote Access Service (RRAS), or both.

• Перед установкой служб Active Directory сертификатов необходимо присвоить компьютеру имя, настроить компьютер со статическим IP-адресом и присоединить компьютер к домену. Before you install Active Directory Certificate Services, you must name the computer, configure the computer with a static IP address, and join the computer to the domain. Дополнительные сведения о выполнении этих задач см. в разделе сетевого руководствапо Windows Server 2016 Core. For more information on how to accomplish these tasks, see the Windows Server 2016 Core Network Guide.
• Для выполнения этой процедуры компьютер, на котором устанавливается AD CS, должен быть присоединен к домену, где установлена служба домен Active Directory Services (AD DS). To perform this procedure, the computer on which you are installing AD CS must be joined to a domain where Active Directory Domain Services (AD DS) is installed.

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

Чтобы выполнить эту процедуру с помощью Windows PowerShell, откройте Windows PowerShell и введите следующую команду и нажмите клавишу ВВОД. To perform this procedure by using Windows PowerShell, open Windows PowerShell and type the following command, and then press ENTER.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

После установки AD CS введите следующую команду и нажмите клавишу ВВОД. After AD CS is installed, type the following command and press ENTER.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Установка служб сертификатов Active Directory To install Active Directory Certificate Services

Если вы хотите использовать Windows PowerShell для установки служб Active Directory Certificate Services, см. раздел Install-адксцертификатионаусорити для командлетов и необязательных параметров. If you want to use Windows PowerShell to install Active Directory Certificate Services, see Install-AdcsCertificationAuthority for cmdlets and optional parameters.

Войдите в систему как член группы «Администраторы предприятия» и группу «Администраторы домена корневого домена». Log on as a member of both the Enterprise Admins group and the root domain’s Domain Admins group.

Откройте диспетчер серверов, щелкните Управление, а затем нажмите кнопку Добавить роли и компоненты. In Server Manager, click Manage, and then click Add Roles and Features. Откроется мастер добавления ролей и компонентов. The Add Roles and Features Wizard opens.

На странице Перед началом работы нажмите кнопку Далее. In Before You Begin, click Next.

Страница Перед началом работы мастера добавления ролей и компонентов не отображается, если при предыдущем запуске мастера был установлен флажок Пропустить эту страницу по умолчанию. The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected Skip this page by default when the Add Roles and Features Wizard was run.

На странице Выбор типа установки убедитесь, что выбрана Установка ролей или компонентов, затем нажмите кнопку Далее. In Select Installation Type, ensure that Role-Based or feature-based installation is selected, and then click Next.

На странице Выбор целевого сервера убедитесь, что выбран пункт Выберите сервер из пула серверов. In Select destination server, ensure that Select a server from the server pool is selected. На странице Пул серверов проверьте, что выбран локальный компьютер. In Server Pool, ensure that the local computer is selected. Щелкните Далее. Click Next.

В окне Выбор ролей сервера в списке роли выберите Active Directory службы сертификации. In Select Server Roles, in Roles, select Active Directory Certificate Services. Когда появится запрос на добавление необходимых компонентов, щелкните Добавить компоненты, а затем нажмите кнопку Далее. When you are prompted to add required features, click Add Features, and then click Next.

В окне Выбор компонентов нажмите кнопку Далее. In Select features, click Next.

В Active Directory службах сертификации прочтите предоставленные сведения и нажмите кнопку Далее. In Active Directory Certificate Services, read the provided information, and then click Next.

На странице Подтверждение выбранных элементов для установки нажмите кнопку Установить. In Confirm installation selections, click Install. Не закрывайте мастер в процессе установки. Do not close the wizard during the installation process. После завершения установки щелкните настроить Active Directory службы сертификатов на целевом сервере. When installation is complete, click Configure Active Directory Certificate Services on the destination server. Откроется мастер настройки служб сертификатов Active Directory. The AD CS Configuration wizard opens. Прочтите учетные данные и при необходимости укажите учетные данные для учетной записи, которая является членом группы «Администраторы предприятия». Read the credentials information and, if needed, provide the credentials for an account that is a member of the Enterprise Admins group. Щелкните Далее. Click Next.

В службах ролей щелкните центр сертификации, а затем нажмите кнопку Далее. In Role Services, click Certification Authority, and then click Next.

На странице тип установки убедитесь, что выбран параметр ЦС предприятия , и нажмите кнопку Далее. On the Setup Type page, verify that Enterprise CA is selected, and then click Next.

На странице Укажите тип страницы ЦС убедитесь, что выбран параметр корневой ЦС , и нажмите кнопку Далее. On the Specify the type of the CA page, verify that Root CA is selected, and then click Next.

На странице Указание типа закрытого ключа убедитесь, что выбран параметр создать новый закрытый ключ , а затем нажмите кнопку Далее. On the Specify the type of the private key page, verify that Create a new private key is selected, and then click Next.

На странице шифрование для центра сертификации сохраните параметры по умолчанию для CSP (поставщик хранилища ключей RSA) и алгоритм хэширования (SHA2) и определите максимальную длину символов ключа для развертывания. On the Cryptography for CA page, keep the default settings for CSP (RSA#Microsoft Software Key Storage Provider) and hash algorithm (SHA2), and determine the best key character length for your deployment. Большие ключевые длины символов обеспечивают оптимальную безопасность; Однако они могут повлиять на производительность сервера и могут быть несовместимы с устаревшими приложениями. Large key character lengths provide optimal security; however, they can impact server performance and might not be compatible with legacy applications. Рекомендуется использовать значение по умолчанию 2048. It is recommended that you keep the default setting of 2048. Щелкните Далее. Click Next.

На странице имя ЦС сохраните Предлагаемое общее имя ЦС или измените имя в соответствии с вашими требованиями. On the CA Name page, keep the suggested common name for the CA or change the name according to your requirements. Убедитесь, что имя ЦС совместимо с соглашениями об именовании и целями, так как вы не можете изменить имя ЦС после установки служб AD CS. Ensure that you are certain the CA name is compatible with your naming conventions and purposes, because you cannot change the CA name after you have installed AD CS. Щелкните Далее. Click Next.

На странице срок действия в поле Укажите срок действия введите число и выберите значение времени (годы, месяцы, недели или дни). On the Validity Period page, in Specify the validity period, type the number and select a time value (Years, Months, Weeks, or Days). Рекомендуется использовать значение по умолчанию, равное пяти годам. The default setting of five years is recommended. Щелкните Далее. Click Next.

На странице база данных ЦС в поле укажите расположения базы данных укажите расположение папки для базы данных сертификатов и журнала базы данных сертификатов. On the CA Database page, in Specify the database locations, specify the folder location for the certificate database and the certificate database log. Если указаны расположения, отличные от расположений по умолчанию, убедитесь, что папки защищены с помощью списков управления доступом (ACL), которые не позволяют неавторизованным пользователям или компьютерам получать доступ к базе данных и файлам журналов ЦС. If you specify locations other than the default locations, ensure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Щелкните Далее. Click Next.

В окне Подтверждение нажмите кнопку настроить , чтобы применить параметры, а затем нажмите кнопку Закрыть. In Confirmation, click Configure to apply your selections, and then click Close.

Установка центра сертификации на предприятии. Часть 3

А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В нашем конкретном случае будут использоваться только две переменные: и . Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(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 необходимо выполнить следующую команду:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is the first part of a seven-part series explaining and setting up a two-tier PKI with Windows Server 2016 or Windows Server 2019 in an enterprise SMB setting, where the hypervisor (host) is running the free Hyper-V Server 2016 or Hyper-V Server 2019, all Certificate Authorities (CA’s) and IIS servers are running Windows Server 2016 or Windows Server 2019.

This series was designed for those who are about to, or already have, implemented a production enterprise PKI and to serve as a guide through the process in a real-life manner.  Many other guides are similarly designed, but are more geared towards test environments, using defaults, and not exactly considering real-life scenarios and practices.  My aim is to tie up any loose end questions or needed help regarding the deployment, or to act as a template when trying to troubleshoot existing deployments.

>>> Part 1 (Informational) <<<
Part 2 (Getting Started & IIS Web Server Configuration)
Part 3 (Standalone Offline Root CA Configuration)
Part 4 (Enterprise CA Configuration)
Part 5 (Distributing Certificates & AutoEnrollment)
Part 6 (Additional Configuration)
Part 7 (Troubleshooting & Clean-up)

PKI Planning

This is the most important step, as it determines how you do everything moving forward.

You must plan carefully, taking into consideration where your PKI implementation may lead down the road.  If you need to make changes later (or sooner), or you found you made a mistake or need to make a change after you have already distributed certificates to users and devices, you will most likely need to re-deploy those certificates.  It depends on what the mistake or change is, of course, but this is usually a huge pain.  Now don’t worry, if it happens or has already happened, I will show you how to get started cleaning it up.

Here are a couple common questions to ask, when using your own certificates for these instances:

• Will you require public access to your CA services?
  • S/MIME certificates for e-mail digital signatures and encryption
    • If you plan to use it in any way outside of your LAN, such as with Office 365, external users, Outlook clients off-LAN, etc.
• Will you be implementing DirectAccess?
• Will you be implementing IPsec or another type of network infrastructure that requires certificates?
• Will you be implementing Single Sign-On (SSO) or Active Directory Federation Services (AD FS)?
  • Single sign-on with with Office 365, for example.
• How many users and devices will your PKI support?  This series is directed towards SMBs, but even still…
  • Maybe you need to plan for three-tier, multi-site, or multiple Enterprise CA’s at the second or third tier.
• Will you need support for SSL certificates for internal web services?
• Do you want private key archival for the ability to recover Domain user certificates?
• Will you need to implement OCSP?  Will you want to in the future?

Assumptions and Series Outline

In an effort to prevent this series from growing too large to be immediately helpful, I’m going to write it with a few common assumptions below.  I know this won’t cover everybody’s situation, but I believe it is enough to get you set up and going strong.  This can also serve as a brief non-exclusive outline of what I will be covering in this series.

• Certificates will need to be validated publicly, as in the S/MIME example above.
• Running with S/MIME, plus file encryption implementation first, then expanding later.
• Certificates will be distributed automatically via AutoEnrollment for local Domain users and/or devices, with the ability to distribute certificates to external users who are not on the domain, network, or who may not be local.
• The PKI will be set up in a typical SMB setting that doesn’t require three tiers, or multiple Enterprise CA’s per tier, but will leave it open as an option.
• Assuming you care about the security of your CA’s, in that the CA’s themselves will not be directly accessible publicly, and will publish to or put that off to the IIS server.
• Leave open the possibility that DA, IPsec, SSO, AD FS, and other needs may come in the future.
• Email users will include Outlook and Thunderbird users on Windows 7 to 10, OSX, iOS, and Android — how to get digital signatures and encryption working on it all.
• SSL certificates for web servers and services distribution.
• Private key archival implementation (and recovery) for AutoEnrollment domain users.
  • Although some companies may have policies in place that not allow this, I will cover it anyways.
• I will not be covering OCSP immediately in this series.  In a typical SMB, there are no performance benefits to using OCSP, as the CRL files will be so tiny.  I will, however, add it in and link to it later.
  • Newer Windows prefer OCSP over CRLs first, but regardless, I will still add it later.
  • OCSP info is in certificates, so if you implement it later, it will only effect new certificates.

The Design

Here I will lay out the design, and briefly explain some how’s and why’s.

1. Off-line, Off-domain Root CA
   1. Domain-joined Enterprise (issuing) CA
   2. Domain-joined IIS server

Root CA

The Off-line off-domain RootCA is turned off, and kept off, after the Enterprise CA (issuing CA) is set up.  You may take it a step further and move the RootCA virtual machine off the host entirely, to some form of “in the cabinet” storage.  This is done to pretty much guarantee it’s security.  If the Root CA is compromised, the entire PKI; all certificates at every level, are also considered compromised.  At least if a subordinate or enterprise CA is compromised, only the certificates distributed by that CA are considered compromised.

The off-line RootCA is only to be turned on in the following cases:

1. If you need to renew the Root CA or Issuing CA (tier 2) certificate.
2. You need to add another 2nd tier Enterprise or Subordinate CA.
3. A second tier CA is compromised and you need to revoke it’s certificate.
4. To renew or republish the Root CA’s CRL (certificate revocation list).  Root CA’s really do not need Delta CRLs.
   1. You would need to renew / republish this if you haven’t changed the “CRL publication interval” of the Root CA.  In that case, you would need to turn it on periodically to republish at default interval.
      1. To overcome this, set it to a high number such as 10 or 20 years (the same or lower than the expiration of your Enterprise CA’s certificate).  If you happen to revoke a 2nd tier CA certificate in the meantime, then you can simply turn it on and republish the CRL.

Enterprise CA

The domain-joined Enterprise or Issuing CA’s job will be to only issue certificates, and to publish CRL’s and Delta CRL’s (to the IIS server) at an interval that works best for your environment.  We don’t want a CA accessible from the internet, or to be responsible for certificate CRL look-ups and other web services.  I like to deploy it like this to keep the CA’s safer.

IIS Server

The domain-joined IIS server will be the server providing all other services.  This is where the Root CA and Enterprise CA will publish their CRLs (the CDP), where the AIA will link to, and what the CRL url will point to on all certificates (unless you will host it somewhere else).  Because of this, you will want to make sure the locations are publicly accessible URLs.  Even if your IIS server is not publicly accessible, you still need to use publicly routable URLs in anything you include in the certificates themselves.  I will explain this better later in the series, but you can always copy the CRLs and Delta CRLs to the publicly accessible web server where the CRL and AIA urls point to on the certificates.  This IIS server is also where the CertSrv service will be hosted.

Next Steps

Now that we have some of the more important background and information out of the way, the next step is to set up the servers.