Contents of this directory is archived and no longer updated.

Update 11.11.2010: Windows Server 2008 R2 Standard не поддерживает роль OCSP Responder.


Ссылки на другие материалы из этой серии:

Prologue

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

PKI tasks

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

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

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

Planning CA hierarchy

В одном из своих предыдущих постов я вёл дискуссию об иерархиях PKI: Обсуждение схем иерархии Certification Authority. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии. Двухуровневая иерархия выглядит крайне привлекательно:

2-tier CA hierarchy

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

2-tier CA hierarchy

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

Planning CA types

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

  • Standalone

Характеризуются нетребовательностью к наличию домена Active Directory. Так же Standalone CA не использует шаблоны, следовательно вы не можете запрашивать сертификаты на таком CA через оснастку Certificates консоли MMC. Что означает, что вы не можете пользоваться функциями autoenrollment'а. Так же при выдаче сертификатов, Standalone CA не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера. Энролить сертификаты в Standalone CA можно только через Enrollment Web Pages, либо вручную генерируя запросы (файлы с расширением .req) и отправляя их через оснастку CertSrv.msc. Причём отправка запросов через оснастку CertSrv.msc является новой возможностью в Windows Server 2008. В связи с этим необходимость в Enrollment Web Pages отпала совсем.

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

  • Enterprise

Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на Standalone CA по своим возможностям. Во-первых Enterprise CA требует наличия домена для хранения там своей информации и шаблонов сертификатов. Данный тип CA имеет очень большие возможности по выдаче и обслуживанию сертификатов. Enterprise CA не требует генерации файлов запросов со стороны клиентов, а позволяет подавать заявки на сертификаты через оснастку Certificates консоли MMC и автоматически распространять сертификаты в масштабах целого леса AD при минимальном участии конечного пользователя. Чаще всего это участие сводится к настройке администратором политик autoenrollment'а и всё. Плюс, 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 не будет издавать сертификаты конечным потребителям, а только для других центров сертификации.

Planning validity periods

На какой срок будем выдавать сертификаты для каждого типа CA? 20 лет мне кажется слишком круто, ведь через 20 лет в вашей компании может всё круто поменяться и если ваш бизнес не завязан на предоставлении услуг цифровых сертификатов, 20 лет, наверное, слишком большой срок. А вот 10 лет для корневого и издающего будет вполне достаточно. Не надо думать, что через 10 лет всё умрёт. Просто через 10 лет (фактически чуть раньше, через 8-9 лет) вам придётся обновить сертификаты обоих CA и всё, жизнь будет продолжаться дальше. Издержки на обновлении сертификатов CA минимальные, поскольку никаких изменений в конфигурации производить не придётся.

Planning CDP/AIA extensions

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

Исходя из описанного по ссылкам (читать обязательно!) мы полностью откажемся от LDAP-ссылок и в сертификатах будем публиковать только ссылки на HTTP. Для этой цели нам потребуется веб-сервер, который будет хранить наши CRL/CRT файлы и поддерживать работоспособность ссылок. Поскольку корневой CA не будет издавать сертификаты конечным потребителям, а только для других CA, риск компрометации которых невелик (но всё же существует) и он большую часть времени будет выключен, мы отключим публикацию Delta CRL для корневого CA, но включим для Issuing CA. Основной CRL (Base CRL) мы будем публиковать каждые 3 месяца для корневого сертификата и каждые 5 дней для Issuing CA. Для обеспечения более быстрой реакции на отзыв сертификатов, для Issuing CA будем публиковать Delta CRL каждые 12 часов.

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

Conclusion

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

  1. Windows Server 2008/2008 R2 Standard Edition.
    Компьютер является членом рабочей группы WORKGROUP, с именем хоста RootCA. Компьютер не подключен к локальной сети или к интернетам. В принципе, для это задачи можно использовать и Enterprise/Datacenter редакции, но от них вы никакого профита не получите в случае использования роли ADCS (Active Directory Certificate Services). Редакции Standard хватит вполне.
  2. Windows Server 2008 Enterprise/Datacenter или Windows Server 2008 R2 Standard/Enterprise/Datacenter.
    Компьютер является членом домена Adatum.com с именем хоста Issuing CA. Компьютер не должен держать роль контроллера домена.
  3. Домен Adatum.com содержит выделенный веб-сервер под управлением любой ОС и который доступен из интернета (только для обслуживания внешних клиентов).
  4. Домен Adatum.com содержит сервер способный выполнять роль OCSP Responder'а. Если это будет Windows Server, требования к версии будут такие же, как и для Enterprise CA. Т.е. Windows Server 2008 R2 Standard/Enterprise/Datacenter или Windows Server 2008 Enterprise/Datacenter.

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


Share this article:

Comments:

yack
yack 25.03.2010 09:10 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Вадим, хотел уточнить. Возможно ли использовать для standalone root CA windows 2003, а для Enterprise Policy/Issuing CA windows 2008 R2?

Vadims Podāns
Vadims Podāns 25.03.2010 12:26 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Да, можно. Версия ОС, под которой работает CA может быть любой даже non-Windows. Просто я отмечал, что отдельно по 2003 ничего не буду писать, т.к. новые инсталляции на нём уже очень мало делают.

Konstantin
Konstantin 30.03.2010 13:10 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Мне бы раньше попасть на этот блог! Я бы не думал отчаянно отчего у меня авторегистрация не отрабатывает как надо :). Спасибо за инфу! Very usefull!

lordgraill.livejournal.com
lordgraill.livejournal.com 31.03.2010 09:40 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

в первую очередь спасибо за ликбез ) хотелось задать такой вопрос - предположим в системе есть только один сервер сертификации, кто-то его взломал. Что он теперь может сделать (помимо выдачи липовых сертификатов, естественно)? и еще - если скомпрометирован "старший сертификат", после этого заменен - значит ли это что необходимо заменять все клиентские сертификаты (для чтения зашифрованной почти, например)? сорри за нубские вопросы

Vadims Podāns
Vadims Podāns 31.03.2010 12:07 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Попробуем попорядку. > Что он теперь может сделать (помимо выдачи липовых сертификатов, естественно)? а больше ему ничего не надо делать. Достаточно выпускать поддельные сертификаты, которые будут идентифицировать поддельных пользователей. Т.е. поддельные пользователи будут аутентифицироваться под логинами легитимных пользователей. > и еще - если скомпрометирован "старший сертификат", после этого заменен - значит ли это что необходимо заменять все клиентские сертификаты (для чтения зашифрованной почти, например)? Что значит "старший"? Это корневой или ниже корня? Корневой сертификат, как я и говорил не подлежит стандартному методу отзыва. И его аннулирование — крайне нетривиальная операция и зачастую это невозможно сделать полностью. Т.е. его надо вручную удалять из контейнера Trusted Root CAs. Если в домене это относительно просто, то с недоменными клиентами будет ещё хуже. Безусловно, аннулирование (отзыв) любого сертификата CA влечёт автоматическое аннулирование всех сертификатов в его цепочке. В случае аннулирования корневого сертификата, все сертификаты в его цепочке будут недействительны, поскольку этот корневой сертификат не является доверенным. Это одна из причин, почему корневые CA нуждаются в особенной защите. Что касается шифрования, тут есть другой момент, который зависит от самих приложений. Как приложения настроены на проверку отзыва, так они работать и будут.

lordgraill.livejournal.com
lordgraill.livejournal.com 31.03.2010 13:31 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

понял, спасибо и можно еще вопрос? у нас в домене развернут сервер сертификатов, сочетающий в себе все функции, в том числе root ca. Устанавливался когда-то давно неизвестно кем, судя по всему, next-next'ом и использовался в исключительно для выдачи сертификатов на шифрование почты. Я так понимаю, если я вывожу его из домена и пытаюсь менять структуру на двухкомпонетную, все ранее выданные сертификаты становятся недействительными? И стоит ли заморачиваться этой процедурой, или проще поднять все заново, по-человечески настроив? Оставить все как есть нельзя, т.к. планируется расширение функционала службы сертификации (в том числе - распространение на филиалы).

Vadims Podāns
Vadims Podāns 31.03.2010 14:10 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Я считаю, что старый CA следует декомиссовать: http://support.microsoft.com/kb/889250 и разворачивать всё с нуля. Правда, это зависит от уровня текущего использования. Т.е. на сколько критично использование текущих сертификатов. Т.е. если они серьёзно используются, то рекомендуется параллельно развернуть новую инфраструктуру, планово всё на неё перенести и только когда всё будет завершено, старую инфраструктуру можно будет удалять.

alexiszp.livejournal.com
alexiszp.livejournal.com 06.04.2010 17:48 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Добрый день, натолкнулся на Вашу статью, решил поднять свой уровень в плане сертификатов :) При попытке поднять enterprise CA мне недоступна к выбору опция enterprise CA(затемнена), доступна только standlaone. По конфигурации, два сервера 2008R2, один контроллер домена, второй просто член домена без каких-либо ролей, на него я и пытаюсь установить enterprise CA. Вашу инструкцию заодно и сравниваю с пошаговым руководством от Microsoft по 2008 серверу(версия от апреля 2007).

Vadims Podāns
Vadims Podāns 06.04.2010 18:22 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Убедитесь, что: 1) вы залогонены под доменной учётной записью, а не под локальной. 2) Убедитесь, что ваша доменная учётная запись является членом группы Enterprise Admins.

alexiszp.livejournal.com
alexiszp.livejournal.com 07.04.2010 12:49 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Протупил, однако :) действительно, я заходил под локальным админом. Большое спасибо! ;)

pgarmashov
pgarmashov 11.11.2010 15:03 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Про Conclusion - 4. Если http://www.microsoft.com/windowsserver2008/en/us/r2-compare-roles.aspx не врут, то OCSP на 2008 R2 Standard запустить не удастся (хотя мне никогда не приходило в голову это проверять, возможно, что ограничение исключительно лицензионное). В остальном - пожалуй, это один из лучших гайдов по сборке PKI на Windows :)

Vadims Podāns
Vadims Podāns 11.11.2010 16:25 (GMT+3) Устанавливаем Certification Authority (часть 1) — Введение

Да, тут я оплошал, Standard не поддерживает OCSP. Исправлено.

Comments are closed.