Развертывание PKI
Развертывание PKI, нетривиальный процесс, как бы легче не стало с выходом Windows Server 2008 R2.
Данный пост написан с единственной целью, если придется повторить, то не забыть что-то сделать. Возможно кому-то какая-то часть этих записей поможет. Но всё написанное ниже, не может служить инструкцией! В моих условиях требуется развернуть PKI на тестовом домене разработчика.
Проблемы с компрометацией сертификата Root CA не стоят. Поднять новый единый Online Root/Poliсy/Issuing CA в моих условиях выгоднее, чем поддерживать безопасный вариант, который просто необходим в условиях реальной эксплуатации.
Поэтому варианты инфраструктуры с Offline Root CA являются явным излишеством, да еще и требуют времени на ручную поддержку. Отказ от LDAP ссылок в AIA в пользу HTTP тоже не подходит.
Про то, как правильно развернуть PKI в боевых условиях, можете прочесть:
Начальные условия
- Настроенный AD на Windows Server 2008 R2 Standard/Enterprise/Datacenter SP1;
- Будущий сервер Online Root/Poliсy/Issuing CA — Windows Server 2008 R2 Enterprise/Datacenter SP1 — является членом домена;
Поскольку домен тестовый, выключаем все машины члены домена, делаем snapshot (я надеюсь, никто не держит подобную тестовую инфраструктуру на реальном железе?) всех машин в домене, на случай, если придется откатиться в самое начало.
Планирование
Установка PKI даже в таких простейших условиях не может быть выполнена простым Next — Next. Основные вопросы и примеры планирования читайте в статье:
Планирование инфраструктуры PKI
Предварительная настройка
Перед развертыванием роли CA имеет смысл внести несколько изменений в групповую политику домена. Это всё равно потребуется позже, и нет никаких причин сделать это прямо сейчас.
Предварительная настройка перед установкой Certification Authority
Формирование CAPolicy.inf
Перед установкой CA, стоит создать файл конфигурации CAPolicy.inf. Установщик роли будет использовать эту информацию при установке.
Установка роли Active Directory Certificate Services
Благодаря заранее проведенному планированию, установка роли AD CS не вызывает серьезных вопросов.
Установка роли Active Directory Certificate Services
Сразу после установки роли AD CS нужно будет выполнить настройку CA, поскольку вносимые изменения касаются содержимого издаваемых сертификатов, и должны быть выполнены до издания первого сертификата.
Настройка CA
После установки роли AD CA требуется выполнить еще несколько действий:
- Задание точек публикации CRL файлов, а также ссылки в издаваемых сертификатах
- Задание ссылок на CRT публикуемые в издаваемых сертификатах
- (не обязательно) Изменить срок действия издаваемых сертификатов
- (не обязательно) Изменить сроки публикации Base CRL и Delta CRL
- (не обязательно) Включить аудит для CA
- Перезапуск CA для принятия внесенных изменений
Все эти операции выполняются скриптом, который был подготовлен ранее, на этапе планирования инфраструктуры PKI.
Настройка OCSP
Роль OCSP Online Responder была установлена ранее, теперь нужно настроить Online Responder.
Настройка OCSP Online Responder
Настройка IIS
Настройка IIS в моем случае была проведена автоматически при установке ролей. Запустите Best Practice Analyzer вашего CA, он проверит, в т.ч. настройки IIS. На всякий случай, инструкция по настройке IIS ниже.
Для правильной обработки CRL, IIS должен быть настроен на двойной эскейпинг для корректного восприятия знака плюс (+) в ссылках. Для этого необходимо включить опцию DoubleEscaping. Подробнее в technet: AD CS: Web server should allow URI containing the «+» character to enable publishing of delta CRLs.
Для настройки фильтра запросов:
- На сервере 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. Теперь следует проверить всё ли правильно было сделано.
Проверка Certification Authority
Заключение
Windows CA установлен и настроен. И это самая простая, одноуровневая иерархия PKI, которую нигде, кроме как в тестовых условиях, использовать нельзя, по причинам безопасности.
Самая главная проблема в Root CA, из за его сертификата, который невозможно отозвать. Секретный ключ этого сертификата можно сравнить с печатью предприятия.
HTTP сервер расположенный на CA сервере еще одна потенциальная возможность для взломщиков, а в случае ограниченного количества IP адресов у компании, еще и сложности с доступом к нему из интернет. Двухуровневая иерархия значительно более приспособлена к реальным условиям. Даже если HTTP будет расположен на сервере с Issuing CA и этот CA будет скомпрометирован, остается возможность отозвать сертификат скомпрометированного Issuing CA и уменьшить потери в репутации компании. Хотя объем работ по восстановлению инфраструктуры PKI, т.е. замены абсолютно всех сертификатов будет колоссальным. По этой причине серверам CA требуется максимально возможная защита от взлома. А после подозрений на компрометацию сервера CA, стоит начать процедуру смены ключей, не дожидаясь последствий выпуска недоброжелателями поддельных сертификатов.
Полезное
Полезные сведения не вошедшие в другие разделы.
certsrv.msc /e — Список всех CRL созданных CA
