Шаг за шагом: Миграция Active Directory Certificate Service с Windows Server 2003 на Windows Server 2012 R2 / Блог компании Microsoft / Хабр

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

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

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

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

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

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

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

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

Конвертируем и устанавливаем сертификат

Загруженный сертификат certnew.cer нужно передать на веб-сервер любым удобным способом и положить в папку /root. Конвертируем сертификат из DER в формат PEM:

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

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

В конфигурационных файлах apache, внутри нужного виртуального хоста с включенным SSL, меняем значение параметров:

Mac os x

1. Перейдите в каталог, в котором установлена Java. Это обычно

cd / Library / Java /Home

2. Выполните приведенную ниже команду, где server-certificate.crt – это имя файла с вашего сервера каталогов:

sudo keytool -importcert -keystore ./jre/lib/security/cacerts -file server-certificate.crt

3. keytool запросит пароль. Пароль ключевого хранилища по умолчанию – changeit.
4. При запросе Подтвердите этот сертификат? [no]: введите yes для подтверждения импорта ключа:

Password:
Enter keystore password: changeit
Owner: CN=ad01, C=US
Issuer: CN=ad01, C=US
Serial number: 15563d6677a4e9e4582d8a84be683f9
Valid from: Tue Aug 21 01:10:46 ACT 2007 until: Tue Aug 21 01:13:59 ACT 2021
Certificate fingerprints:
         MD5:  D6:56:F0:23:16:E3:62:2C:6F:8A:0A:37:30:A1:84:BE
         SHA1: 73:73:4E:A6:A0:D1:4E:F4:F3:CD:CE:BE:96:80:35:D2:B4:7C:79:C1
Trust this certificate? [no]:  yes
Certificate was added to keystore

Теперь вы можете изменить «URL», чтобы использовать LDAP через SSL (т. Е. Ldaps: // <HOSTNAME>: 636 /) и использовать параметр «Безопасный SSL» (Secure SSL) при подключении приложения к серверу каталогов.

Online certificate status protocol

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

. Как показывает практика, в большинстве случаев установка и поддержка 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 для этого издателя.

Windows

1. Перейдите в каталог, в котором установлена Java. Вероятно, это называется

C:Program FilesJavajdk1.5.0_12.

cd /d C:Program FilesJavajdk1.5.0_12

2. Выполните приведенную ниже команду, где server-certificate.crt – это имя файла с вашего сервера каталогов:

keytool -importcert -keystore .jrelibsecuritycacerts -file server-certificate.crt

3. keytool запросит пароль. Пароль ключевого хранилища по умолчанию – changeit.
4. При запросе Доверять этому сертификату? [no]: введите yes для подтверждения импорта ключа:

Введите пароль хранилища ключей: changeit
Владелец: CN = ad01, C = США
Эмитент: CN = ad01, C = США
Серийный номер: 15563d6677a4e9e4582d8a84be683f9
Действительно с: Вт Авг 21 01:10:46 ACT 2007 до: Вт Авг 21 01:13:59 ACT 2021
Отпечатки сертификата:
    MD5: D6: 56: F0: 23: 16: E3: 62: 2C: 6F: 8A: 0A: 37: 30: A1: 84: BE 
    SHA1: 73: 73: 4E: A6: A0: D1: 4E: F4: F3: CD: CE: BE: 96: 80: 35: D2: B4: 7C: 79: C1 
Доверять этому сертификату? [нет]: да 
Сертификат был добавлен в хранилище ключей 

Теперь вы можете изменить «URL», чтобы использовать LDAP через SSL (т. Е. Ldaps: // <HOSTNAME>: 636 /) и использовать параметр «Безопасный SSL» (Secure SSL) при подключении приложения к серверу каталогов.

Издающий цс

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

Корневой цс

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

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

Об авторе

Вадим Поданс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 2021 году, Windows PKI Team провела тесты производительности с использованием более современного оборудования (образца 2007 года) под управлением Windows Server 2008. С результатами можно ознакомиться в их блоге: Windows CA Performance Numbers.

Данные в этих статьях, говорят о том, что сервер AD CS на аппаратном сервере выпуска 2007 года позволяет выпускать порядка 150 сертификатов в секунду. Реальная же потребность в скорости выдачи сертификатов на порядки ниже. Поэтому для ЦС общего назначения советую ориентироваться на рекомендуемые аппаратные требования к самой ОС.

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

Планирование имён цс

Имя ЦС – это имя, которое будет отображено в поле

Subject

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

Для Standalone CA: <ComputerName>-CA

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

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

Предположим, что вы подбираете имя для корневого ЦС компании 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]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
• Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, ā, ž, Ü, ẞ). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.

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

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

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

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

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

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

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

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

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

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

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

Похожие темы

Подключение к каталогу LDAP

Настройка пользовательских каталогов

Предпосылки

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

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

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

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

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

Размышления

Размышления крайне просты:  для экономии бюджета  PKI-AD будет установлена непосредственно на сервер  Active Directory, а вот ROOT-CA требуется поднять на Linux.

Далее по тексту:

Решение

Подготовка ROOT-CA.   (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет  easy-rsa,  который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

 Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.  

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог – в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/  

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

Сервер iis

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

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

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

Шаг 1. резервная копия конфигурации и базы данных центра сертификации windows server 2003

Заходим в Windows Server 2003 под учетной записью из группы локальных администраторов.

Выбираем

Шаг 1. установите службы сертификации active directory

Если службы сертификации уже установлены, перейдите к шагу 2 ниже. Скриншоты ниже приведены с сервера 2008, но процесс похож на сервер 2000 и 2003.

Шаг 2. получите сертификат сервера

В приведенных выше шагах описано, как установить центр сертификации (CA) на сервере Microsoft Active Directory. Затем вам нужно будет добавить сертификат SSL сервера Microsoft Active Directory в список принятых сертификатов, используемых JDK, который запускает ваш сервер приложений.

Сертификат Active Directory автоматически создается и помещается в корневой каталог диска C: , соответствующий формату файла, аналогичному древовидной структуре сервера Active Directory. Например:

Шаг 2. резервирование параметров реестра центра сертификации

Нажмите

Start

, затем

Run

. Напечатайте

regedit

и нажмите

ОК

Затем откройте

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvc

Щелкните правой кнопкой мыши по ключу

“Configuration”

и выберите

“Export”

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

“Save”

, чтобы закончить резервирование.

Теперь у нас есть резервные файлы центра сертификации и мы можем переместить эти файлы на новый сервер Windows Server 2021 R2.

Шаг 3. импортируйте сертификат сервера

Чтобы сервер приложений мог доверять сертификату своего каталога, сертификат должен быть импортирован в среду выполнения Java. JDK хранит доверенные сертификаты в файле, называемом хранилищем ключей. Файл хранилища по умолчанию называется cacerts, и он живет в подкаталоге jre lib security вашей установки Java.

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

Шаг 3. удаление службы центра сертификации с windows server 2003

Теперь, когда готовы резервные файлы и прежде, чем настроить службы сертификации на новом Windows Server 2021 R2, мы можем удалить службы центра сертификации с Windows Server 2003. Для этого нужно проделать следующие шаги.

Щёлкаем

Start > Control Panel > Add or Remove Programs

Затем выбираем

“Add/Remove Windows Components”

В следующем окне

уберите

галочку с пункта

“CertificateServices”

и нажмите

“Next”

для продолжения

После завершения процесса, вы увидите подтверждение и можете нажать

“Finish”

На этом этапе мы закончили работу со службами центра сертификации на Windows Server 2003 и следующим шагом будем настраивать и конфигурировать центра сертификации на Windows Server 2021 R2.

Шаг 4. установка служб сертификации на windows server 2021 r2

Зайдите на Windows Server 2021 R2 под учетной записью или администратора домена, или локального администратора.

Перейдите в

Server Manager > Add roles and features

Запустится

“Add roles and features”

, нажмите

“Next”

для продолжения.

В следующем окне выберите

“Role-based or Feature-based installation”

, нажмите

“Next”

для продолжения.

Из списка доступных серверов выберите ваш, и нажмите

“Next”

для продолжения.

В следующем окне выберите роль “Active Directory Certificate Services”, установите все сопутсвующие компоненты и нажмите

“Next”

В следующих двух окнах нажимайте

“Next”

. После этого вы увидите варианты выбора служб для установки. Мы выбираем

Certificate AuthorityCertification Authority Web Enrollment

и нажимаем

“Next”

для продолжения.

Для установки

Certification Authority Web Enrollment

необходимо установить

IIS

. Поэтому в следующих двух окнах посмотрите краткое описание роли, выберите нужные компоненты и нажмите

“Next”

Далее вы увидите окно подтверждения. Если все в порядке, нажмите

“Install”

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

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

Шаг 5. настройка ad cs

В этом шаге мы рассмотрим как настроить и восстановить те файлы резервирования, которые мы создали.

Зайдите на сервере с правами

Enterprise

Шаг 6. восстановление зарезервированного ca

Теперь мы переходим к наиболее важной части всего процесса миграции, в которой мы восстановим зарезервированный в Windows Server 2003 CA.

Открываем

Server Manager > Tools > Certification Authority

Щелкаете правой кнопкой мыши по имени сервера и выбираете

AllTasks > RestoreCA

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

ОК

Запустится

Certification Authority Restore Wizard

, нажмите

“Next”

для продолжения.

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

“Next”

для продолжения.

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

“Next”

для продолжения.

В следующем окне нажмите

“Finish”

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

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

Шаг 7. восстановление информации в реестре

Во время создания резервной копии CA мы также создали резервную копию ключа реестра. Теперь нужно ее восстановить. Для этого откройте папку, которая содержит зарезервированный ключ реестра. Щелкните по нему дважды левой кнопкой мыши.

Появится предупреждающее окно. Нажмите

“Yes”

для восстановления ключа реестра.

По окончании вы получите подтверждение об успешном восстановлении.

Шаг 8. перевыпуск шаблона сертификата

Мы завершили процесс миграции, и сейчас нужно перевыпустить сертификаты. У меня были настройки шаблона в окружении Windows Server 2003, который назывался

“PCCertificate”

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

Открывает консоль

Certification Authority

Щелкаем правой кнопкой мышки по

Certificate Templates Folder > New > Certificate Template to Reissue

Из списка шаблонов сертификатов выберите подходящий шаблон сертификата и нажмите

ОК

Шаг 9. тестируем ca

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

Windows 8.1

, назвал его

demo1

и добавил в домен

canitpro.local

. После его первой загрузки, на сервере я открываю консоль центра сертификации и разворачиваю раздел “Issued Certificate”. Там я могу увидеть новый сертификат, который выпущен для компьютера.

На этом процесс миграции успешно завершен.

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

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

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

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

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

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

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

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

Корневой ЦС

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

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

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

Издающий ЦС

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

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

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

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

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

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