Развертывание PKI , нетривиальный процесс, как бы легче не стало с выходом Windows Server 2008 R2 .

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

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

Поэтому варианты инфраструктуры с Offline Root CA являются явным излишеством, да еще и требуют времени на ручную поддержку. Отказ от LDAP ссылок в AIA в пользу HTTP тоже не подходит.

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

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

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

Перед установкой CA , стоит создать файл конфигурации CAPolicy.inf . Установщик роли будет использовать эту информацию при установке.

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

Благодаря заранее проведенному планированию , установка роли AD CS не вызывает серьезных вопросов.

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

Настройка CA

После установки роли AD CA требуется выполнить еще несколько действий:

• Задание точек публикации CRL файлов, а также ссылки в издаваемых сертификатах
• Задание ссылок на CRT публикуемые в издаваемых сертификатах
• (не обязательно) Изменить срок действия издаваемых сертификатов
• (не обязательно) Изменить сроки публикации Base CRL и Delta CRL
• (не обязательно) Включить аудит для CA
• Перезапуск CA для принятия внесенных изменений

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

Настройка OCSP

Настройка IIS

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

Для настройки фильтра запросов:

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

Проверки

Заключение

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

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

HTTP сервер расположенный на CA сервере еще одна потенциальная возможность для взломщиков, а в случае ограниченного количества IP адресов у компании, еще и сложности с доступом к нему из интернет. Двухуровневая иерархия значительно более приспособлена к реальным условиям. Даже если HTTP будет расположен на сервере с Issuing CA и этот CA будет скомпрометирован, остается возможность отозвать сертификат скомпрометированного Issuing CA и уменьшить потери в репутации компании. Хотя объем работ по восстановлению инфраструктуры PKI , т.е. замены абсолютно всех сертификатов будет колоссальным. По этой причине серверам CA требуется максимально возможная защита от взлома. А после подозрений на компрометацию сервера CA , стоит начать процедуру смены ключей, не дожидаясь последствий выпуска недоброжелателями поддельных сертификатов.

Полезное

Полезные сведения не вошедшие в другие разделы.

certsrv.msc /e — Список всех CRL созданных CA

Здравствуйте, друзья!

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

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

В наших примерах мы будем использовать контроллер домена на Microsoft Windows Server 2008 и клиент Microsoft Windows 7.

1. Для начала нам нужно добавить роль (Службы сертификации Active Directory ) на контроллере домена. Откройте Server Manager и выполните команду «Add Role» («Добавить роли» ).
2. Откроется Add Roles Wizard (Мастер добавления ролей ). Нажмите Next .
   
   
3. Выберите роль Active Directory Certification Services (Службы сертификации Active Directory) . Нажмите Next .
   
   
4. Next .
   
   
5. Проверьте, что отмечена служба Certification Authority (Центр сертификации) .
   
   
6. Вариант установки должен быть указан «Enterprise» .
   
   
7. Тип центра сертификации Root CA (Корневой ЦС) .
   
   
8. Создайте новый приватный ключ.
   
   
9. Укажите параметры шифрования, например:
   
   
   Если Вы меняете параметры, рекомендуем Вам ознакомиться с советами компании Microsoft по безопасности в части выбираемой длины ключа.
10. Проверьте имя и суффиксы центра сертификации, например:
    
    
11. Задайте срок действия сертификата, например:
    
    
12. Next .
    
    
13. Install.
    
    
14. Процесс установки…
    
    
15. Установка завершена. Close .
    
    
    Центр сертификации установлен. Теперь нужно создать шаблон сертификатов.
16. Перейдите в Certificate Templates (Шаблоны сертификатов ) и выполните команду Duplicate Template (Скопировать шаблон ) на существующем шаблоне, например User .
    
    
17. Выберите версию Windows Server минимально поддерживаемую ЦС.
    
    
    Не выбирайте Windows Server 2008, иначе при подписании созданным сертификатом документов в программных продуктах использующих.NET Framework 4.0 Вы получите сообщение «Указан неправильный тип поставщика (mscorlib)». Иными словами Вы не сможете использовать сертификат.
18. В открывшихся свойствах шаблона укажите имя и отключите Publish certificate in Active Directory (Опубликовать сертификат в Active Directory ):
    
19. Перейдите на вкладку Request Handling (Обработка запроса ) и измените цель на «Signature» («Подпись» ).
    
20. Проверьте параметры на вкладке Subject Name (Имя субъекта ).
    
21. На вкладке Security (Безопасность ) для группы Authenticated Users (Прошедшие проверку ) разрешите Enroll (Заявка ).
    
22. На вкладке Extensions (Расширения ) скорректируйте Application Policies (Политика применения ) .
    Выберите Document Signing (Подписывание документа ).
    
    ОК.
    Шаблон сертификата создан, теперь необходимо его опубликовать.
23. Перейдите в Certificate Templates (Шаблоны сертификатов ) и выполните команду «New -> Certificate Template to Issue» («Новый -> Выдать шаблон сертификата» ).
    
    
24. Выберите ранее созданный шаблон. ОК.
    
    
    Установка и настройка шаблона сертификатов закончена. Перейдем на клиента и попробуем получить сертификат.
25. На клиенте запустите Certificate Manager Tool выполнив команду certmgr.msc .
    
    
26. Перейдите в Personal (Личное ) и создайте запрос на получение сертификата, выполнив Request New Certificate (Запросить новый сертификат ).
    
    
27. Next .
    
    
28. Выберите политику Active Directory. Next .
    
    
29. В типах сертификатов отметьте ранее созданный шаблон.
    
    
    Если планируется использование нескольких сертификатов для одного пользователя, желательно присвоить имя запрашиваемому сертификату. Откройте свойства заявки.
30. На вкладке General (Общие ) укажите Friendly name (Понятное имя ).
    
    Сохраните и закройте свойства.
31. Enroll.
    
    
32. Заявка успешно завершена, сертификат получен.
    
    
33. В Certificate Manager Tool можно посмотреть параметры сертификата.
    
    
    Мы получили сертификат только для одного пользователя, а когда пользователей много, такой способ не очень удобен. Для облегчения процесса давайте настроим автоматическую раздачу сертификатов групповой политикой.
34. Для начала необходимо изменить свойства, созданного ранее шаблона, сделать его доступным для автоматической выдачи. Найдите созданный шаблон в Server Manager и откройте свойства.
    
    
35. Перейдите на вкладку Security (Безопасность ) и для группы Authenticated Users (Прошедшие проверку ) разрешите Autoenroll (Автозаявка ).
    
36. Следующий шаг — настроить групповую политику автоматической регистрации сертификатов для домена. Можно изменить политику по-умолчанию, но лучше создать новую, так мы сможем ограничить круг пользователей, охватываемых политикой. На домене выполните команду Create a GPO in this domain, and Link it there… (Создать ОГП в документе и связать его… ).
    
    
37. Введите имя групповой политики, например:
    
38. Отредактируйте созданную политику.
    
    
39. Перейдите в раздел «User configuration — Policies — Widows Settings — Security Settings — Public Key Policies» (Конфигурация пользователя — Политики — Конфигурация Windows — Параметры безопасности — Политики открытого ключа ) и откройте свойства Certificate Services Client — Auto-Enrollment (Клиент службы сертификации — автоматическая регистрация ).
    
    
40. Включите автоматическую регистрацию сертификатов и флажки:
    • Обновлять сертификаты с истекшим сроком действия или в состоянии ожидания и удалять отозванные сертификаты;
    • Обновлять сертификаты, использующие шаблоны сертификатов.

    

41. Закройте редактор групповой политики и в Server Manager при необходимости ограничьте круг пользователей или компьютеров, на которые будет применена политика. Как пример, ниже показана политика, которая будет распространена только на ПК DOMAIN\COMPUTER.
    Групповая политика создана, проверим как она работает.
42. На клиенте откройте CMD.exe с правам администратора и выполните команду «gpupdate /force /boot /logoff» или перезапустите ПК.
    
    
43. Сертификат должен быть автоматически запрошен и получен. Полученный сертификат можно увидеть в Certificate Manager Tool (пункт 33) или в Control Panel — Internet Options , вкладка Content — Certificates — Personal (Панель управления — Свойства обозревателя, вкладка Содержание — Сертификаты — Личные ).
    
    
    Это всё, что мы хотели сказать про установку и настройку центра сертификации. Спасибо, что читаете наш блог, до свидания!

Сегодня рассмотрим как развернуть центр сертификации windows, и поговорим для чего он нужен.
Собственный центр сертификации нужен для создания собственной инфраструктуры PKI – Public Key Infrastructure, то есть инфраструктуры открытых ключей. Если говорить в двух словах, то работает эта система так:

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

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

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

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

Сертификаты бывают: Самоподписанные (self-signed) – сервер сам выпускает сертификат, он ни кем не удостоверяется, поэтому ему по умолчанию не будут доверять.

Wildcard сертификаты можно выдавать на область имен – например *.domaim.ru будет действовать на все поддомены.

SAN (Subject Alternative Name) – В такой сертификат можно вписать дополнительные имена серверов, например при публикации OWA, нам потребуется несколько имён,что не делать несколько сертификатов, имена можно вписать в один.

Для установки сервера CA устанавливаем следующие роли:

Выберем сам центр сертифкации, и веб интерфейс:

Enterprise – установка центра в существующий домен:

Сделаем наш сервер корневым:

Сгенерируем новый приватный ключ:

Внимание! Я при установке выбрал алгоритм подписи sha1. Данный алгоритм устарел, и браузер хром ругается, при заходе на сайт.

Поэтому при установке выбирайте минимум sha256. Если же Вы уже установили CA с алгоритмом sha1 поменять его можно через командную строку:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net stop certsvc
net start certsvc

Выбираем имя нашего центра сертификации:

Тут можно выставить время действия корневого сертификата:

Дополнительные сервисы – оставим по умолчанию:

Теперь нам доступен веб интерфейс, по адресу http://dc1/csertsrv

Теперь на серверах мы сможем генерировать запросы на сертификаты, и подписывать их в нашем свежеустановленном центре сертификации. Для этого нужно сгенерировать запрос на сертификат с расширением req, открыть его блокнотом и скопировать запрос в поле, которое находится в веб интерфейсе, под ссылкой Request a certificat. У центра сертификации есть шаблоны, по которым он сможет выпускать сертификаты под разные задачи.

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