Настройка pki windows server 2012 r2

Обновлено: 03.07.2024

Развертывание PKI , нетривиальный процесс, как бы легче не стало с выходом Windows Server 2008 R2 . Данный пост написан с единственной целью, если придется повторить, то не забыть что-то сделать. Возможно кому-то какая-то часть этих записей поможет. Но всё написанное ниже, не может служить инструкцией!

В моих условиях требуется развернуть PKI на тестовом домене разработчика.

Проблемы с компрометацией сертификата Root CA не стоят. Поднять новый единый Online Root/Poliсy/Issuing CA в моих условиях выгоднее, чем поддерживать безопасный вариант, который просто необходим в условиях реальной эксплуатации.

Про то, как правильно развернуть PKI в боевых условиях, можете прочесть :

Начальные условия

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

Планирование

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

Формирование CAPolicy.inf

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

Настройка CA

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

Настройка OCSP

Роль OCSP Online Responder была установлена ранее, теперь нужно настроить Online Responder.

Настройка IIS

Настройка IIS в моем случае была проведена автоматически при установке ролей. Запустите Best Practice Analyzer вашего CA , он проверит, в т.ч. настройки IIS. На всякий случай, инструкция по настройке IIS ниже.

На сервере IIS откройте Server Manager.
Двойной щелчок по Roles, двойной щелчок по Web Server (IIS), и щелчок по IIS Manager.
В дереве консоли щелкните на виртуальном каталоге в котором размещается CRL.
В features view, двойной щелчок по Request Filtering.
В actions view, клините по Edit Feature Settings.
Поставьте галочка на чекбоксе Allow Double Escaping.

Проверки

Сразу после установки роли AD CS в домене, Certification Authority не готов к выпуску сертификатов в соответствии с выполненным планированием. Необходимо было настроить CA. Теперь следует проверить всё ли правильно было сделано.

Заключение

Windows CA установлен и настроен. И это самая простая, одноуровневая иерархия PKI , которую нигде, кроме как в тестовых условиях, использовать нельзя, по причинам безопасности.

Приступим к настройка корневого центра сертификации rca:

Перейдем в папку C:Windows и создадим там файл CAPolicy.inf (кодировка ANSI) следующего содержания:

Сейчас я поясню, какие параметры мы указали этим шагом:

Добавим роль AD CS:

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Затем пройдем по шагам и определим базовые настройки:

Ознакомимся с дефолтными настройками путей к AIA и CDP для нашего корневого CA:

Get-CAAuthorityInformationAccess | fl

Get-CACRLDistributionPoint | fl

Дефолтные расположения нам не походят, поэтому укажем собственные, используя certutil -setreg :

Сейчас я поясню сиснтаксис этих команд:

.. а вот для AIA:

Соответствие переменных значениям для CDP:

Соответствие переменных реальным значениям для AIA:

Укажем параметры списка отзывов (аналогично тому, что было указано в CAPolicy.inf):

certutil -setreg CAAuditFilter 127

Укажем раздел конфигурации в Active Directory:

Перезапустим службу и опубликуем новый список отзывов:

Перенесем (например через виртуальный флоппи-диск) содержимое папки C:Windowssystem32certsrvcertenroll) с сервера rca на сервер dc и опубликуем сертификат корневого ЦС в AD:

certutil –dspublish –f %CaCertFileName.CRT% RootCA

Проверим результат c помощью ADSI Edit:

Теперь опубликуем список отзывов корневого ЦС:

certutil –dspublish –f %CrlFileName.CRL% RootCA

Снова проверим результат с помощью ADSI:

На этом настройку корневого CA можно считать завершенной и переходить к следующим этапам.

А еще грубой ошибкой было игнорирование предупреждения от Microsoft:

Caution-Внимание
Клиенты сертификатов под управлением Windows XP и Windows Server 2003 не поддерживают альтернативный алгоритм подписи. Чтобы такие клиенты могли подавать заявки на сертификаты, не добавляйте строку AlternateSignatureAlgorithm=1 в файл CAPolicy.inf. Дополнительные сведения см. в разделе Рекомендации по использованию альтернативных форматов подписи.

Поэтому — уберите из CAPolicy.inf строку AlternateSignatureAlgorithm=1, иначе заимеете проблему с установкой сертификатов на ASA: Microsoft CA RSASSA-PSS Algorithm Issue with ASA
Решается изменением параметров в реестре:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\%Your_CA_Name%\CSP]
«ProviderType»=dword:00000000
«Provider»=«Microsoft Software Key Storage Provider»
«HashAlgorithm»=dword:00008004
«CNGPublicKeyAlgorithm»=«RSA»
«CNGHashAlgorithm»=«SHA1»
«AlternateSignatureAlgorithm»=dword:00000001
«MachineKeyset»=dword:00000001

и перевыпуском всех сертификатов.

Ну и наконец, третий момент был связан с настройкой параметров SSL на ASA, а именно TLS V1 и соотв. Cipher (версий и алгоритмов). На момент развертывания инфраструктуры PKI у нас была установлена прошивка asa911-smp-k8, которая не позволяла это нормально настроить. Приняли решение обновиться на версию asa941-smp-k8, но снова не совсем внимательно прочли порядок обновления конфигурации. заимели вот такую странную ошибку:

— это при попытке загрузить файл прошивки на железку. А всего лишь необходимо было сначала установить прошивку версии asa912-smp-k8

Надеюсь, кому-то эти знания и опыт пригодятся. Удачи!

ldap attribute-map AD
map-name memberOf IETF-Radius-Class

Ну и наконец, — когда у нас уже настроены CA, установлены все необходимые сертификаты, проверено подключение к AAA серверам, настроен AnyConnect\WebVPN можно включить двухфакторная аутентификация:

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается. К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> . –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI. Вот один из примеров: Помогите установить и настроить службу сертификации. Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка PKI кажется задачей не сложнее администрирования нотепада и укладывается по времени в промежуток обеденного перерыва. При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI (Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC. Я не претендую на попытку устранить этот пробел, поскольку это нереально, но стараюсь дать какие-то полезные понятия и какие-то другие вещи в соответствии с бест-практисами.

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

Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN;
Внедрение защищённых сетевых протоколов — L2TP, SSL, IPsec;
Внедрение защищённой почты с шифрованием и/или подписью писем;
Внедрение цифровых подписей документов и файлов, что гарантирует их целостность и альтернативу ручной подписи.
Внедрение защищённых файловых хранилищ с шифрованием особо конфиденциальной информации.

Если из всего вышеперечисленного вам не нужно, PKI вам не нужна так же.

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

Создание 3-х уровневой иерархии уже будет подразумевать разделение иерерхии на области действий CPS (Certificate Practice Statement) и будут подвержены различным политикам управления серверами CA. Это достаточно долгая песня и о ней говорить не будем. Поэтому мы остановимся на двухуровневой иерархии с одним корневым центром сертификации (Root CA) и одним издающим центром сертификации (Issuing CA).

Microsoft поддерживает два типа центров сертификации — Standalone и Enterprise. Обычно администраторы привыкли устанавливать Enterprise CA и по очевидным причинам не используют Standalone CA. Чем они отличаются?

По своим возможностям Standalone CA выглядит убогим чуть более, чем полностью. Но этот тип CA имеет одно сильное преимущество — он не зависит от наличия домена. Кажется — фигня. Домены даже рулят и педалят и всё, что работает без домена не нужно! Но давайте посмотрим на ситуацию немного с другой стороны. Центры сертификации верхних уровней (корневые и подчинённые центры сертификации первого уровня) имеют как правило очень большой срок действия — от 10 до 20 лет. При этом очень часто домены и леса AD живут значительно меньше, поскольку они постоянно реструктуирутся, переименовываются, мигрируются и т.д. А центр сертификации в домене (Enteprprise CA) лишает нас некоторых возможностей, как переименование домена и усложняют процессы реструктуризации доменов и лесов. По этой причине, Enterprise CA имеет небольшой срок действия своих сертификатов — от 5 до 10 лет максимум. В принципе, если есть независимый от домена AD центр сертификации (Standalone CA в рабочей группе) гораздо проще проводить миграцию и реструризацию лесов AD, поскольку эти процессы не затрагивают корневой CA и избавляют от проблем построения новой иерархии PKI. В такой ситуации достаточно только сменить центры сертификации 2-го и 3-го уровней (последний обычно является Enterprise CA). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

Однако, зависимость от домена вносит некоторые ограничения в свою жизнь. Поскольку домены достаточно подвижные единицы и подвержены изменениям, Enterprise CA имеют достаточно короткий срок действия своих сертификатов — от 5 до 10 лет максимум. В случае Enterprise Root CA, удаление домена автоматически ведёт к краху всей иерархии PKI и её придётся строить с нуля, что может вылиться в большие трудности в довесок к текущим проблемам удаления домена. Именно поэтому компании никогда не устанавливают корневой центр сертификации на Enterprise CA, а только Issuing CA, которые уже издают сертификаты конечным потребителям, где и восстребованы все возможности Enterprise CA. Хотя, в очень небольших компаниях этого будет вполне достаточно, когда корневой CA устанавливается на Enterprise CA и имеет срок действия сертификата 5 лет.

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

Об этом у меня написано уже достаточно много:

Так же можно предусмотреть использование OCSP (Online Certificate Status Protocol). Хоть обычно OCSP и используется только для Enterprise CA, ничего не мешает использовать его для корневого CA. С учётом роста количества клиентов под управлением Windows Vista и выше, это будет хороший экспериенс и я расскажу, как это можно будет реализовать.

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

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

Читайте также: