СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, MCSE, MCSE:S, MCSE:M, MCITP EA, MCITP EMA, HP AIS, msv121@mail.ru

ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, shapiro_leonid@yahoo.com

Инфраструктура открытых ключей
в Windows Server 2016. Часть 3. Issuing CA

В третьей части нашего цикла мы рассмотрим развертывание издающего удостоверяющего центра в двухуровневой иерархии

В отличие от корневого этот сервер должен быть постоянно доступен клиентам, причем здесь мы имеем в виду не только возможность получения сертификатов, но и, что важнее, их отзыва при компрометации. Точно так же, как и с корневым УЦ, перед установкой понадобится подготовить файл capolicy.inf [1] и разместить его в правильном месте [2].

Пример структуры capolicy.inf может выглядеть так:

Познакомиться с синтаксисом файла capolicy.inf можно в первой статье этого цикла [2].

На следующем шаге можно переходить к установке самого сервиса Active Directory Certificate Services. Установка может быть выполнена как с помощью графического интерфейса, так и с помощью команд PowerShell [3]. Второй вариант обычно проще и занимает меньше времени.

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

С точки зрения безопасности следует использовать внешний защищенный носитель информации для обмена и не подключать корневой центр сертификации к сети. Непосредственно для запроса сертификата можно воспользоваться утилитой certreq [4] уже на самом корневом центре сертификации.

где test – папка, в которой был сохранен файл запроса.

Далее запрос одобряется администратором и выдается сертификат для подчиненного центра сертификации.

После этого полученный сертификат переносится на издающий УЦ и устанавливается на нем [5].

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

Первое – опубликовать сертификат корневого центра сертификации на издающем центре сертификатов ICA01, для чего выполнить следующую команду:

Второе – обеспечить доступность CRL корневого центра и его сертификата хотя бы по одному пути, указанному в сертификате.

После этого службу надо запустить:

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

Поскольку мы еще не проводили публикацию сертификата корневого УЦ и его списка отзыва в службе каталога Active Directory Domain Services, это можно будет сделать теперь, для чего выполняются команды:

ROOTCA в данной команде это имя центра сертификации.

На этом заканчивается лишь предварительный этап установки издающего УЦ, следующий шаг – настройка его параметров.

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

Удалите настройки CrlDistributionPoint, заданные по умолчанию.

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

Разумное решение – использование именно внешнего веб-сервера клиентами для получения сертификатов и списков отзыва.

HTTP-путь рекомендуется ставить первым, поскольку это дает возможность клиентам, не имеющим доступа к службе каталога, выполнить проверку списка отзыва сертификатов.

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

Удаление путей можно выполнить с помощью PowerShell:

Для добавления новых путей публикации CrlDistribution-Point выполните следующие команды:

Если с основными компонентами приведенных команд все понятно, то ряд параметров под знаком % может вызывать вопросы. На самом деле здесь нет ничего сложного, и познакомиться с тем, что обозначает каждая из переменных, можно по приведенной ссылке [6].

Для обеспечения автоматической публикации CRL:

По сравнению с корневым центром сертификатов добавляется переменная %9 ( ), так как в ROOTCA список DeltaCRL отсутствует [7].

То же самое следует проделать для AIA-путей, то есть надо удалить настройки CAAuthorityInformationAccess, заданные по умолчанию:

Добавить локальный путь при помощи команды PowerShell не получится, для этого придется воспользоваться графическим интерфейсом или командой certutil.

Добавить пути публикации http и ldap при помощи команд PowerShell.

Для настройки срока действия сертификата и периодичности публикации CRL используется команда certutil, мы подробно рассмотрели постустановочную настройку на примере корневого центра сертификации в предыдущей статье [7].

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

Перезагрузите службу сертификатов:

Опубликуйте списки CRL:

Далее нужно скопировать сертификат издающего центра сертификации в центр распространения (Distribution Point).

Установка и настройка издающего центра сертификации на этом завершена, нам остается проверить, все ли прошло успешно. Для этого используется несколько инструментов.

Графическая консоль сервера сертификатов позволит удостовериться в том, что пути к спискам отзыва и самим сертификатам УЦ изменены, параметры аудита заданы. Также следует удостовериться, что клиенты получают доступ по указанным путям и могут загрузить сертификаты и списки отзыва. В нашем примере это проверка HTTP-пути http://pki.nwtraders.msft/PKI/.

Дополнительно можно обратиться к реестру в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\IssuingCA01\, где IssuingCA01 – это введенное нами при установке имя УЦ, и посмотреть значение ключей реестра:

• CRLPublicationURLs
• CACertPublicationURLs
• ValidityPeriodUnits
• ValidityPeriod
• CRLPeriodUnits
• CRLPeriod
• CRLOverlapUnits
• CRLOverlapPeriod
• CRLDeltaPeriodUnits
• CRLDeltaPeriod
• AuditFilter
• DSConfigDN
• DSDomainDN

Наконец, воспользоваться консолью EnterprisePKI, запустив из командной строки утилиту pkiview.msc, в столбце Status для всех путей должен быть статус OK.

Кроме этого, можно воспользоваться ADSI Edit для проверки информации в службе каталога.

Перейдите по пути CN=Public Key Services,CN=Services,CN=Configuration,DC=Nwtraders,DC=msft.

• AIA – содержит сертификаты центров сертификации, которые клиенты могут извлекать при проверке цепочки сертификатов.
• CDP – содержит CRL (базовый и дельта), которые опубликованы в AD.
• Certificate Templates – cодержит шаблоны сертификатов.
• Certification Authorities – cодержит сертификаты корневых центров сертификации (Root CA для нашего случая).
• Enrollment Services – cодержит сертификаты центров сертификации, которые могут выдавать сертификаты в данной службе каталогов.
• KRA – содержит сертификаты (key recovery agents) агентов восстановления.
• OID – содержит информацию о OID, используемых службой сертификации (Certification Authorities).

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

В следующей статье мы поговорим о работе с центрами распространения (Distribution Points).

Ключевые слова: центр сертификации, служба сертификации, реестры, списки отзыва.

Prologue

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается. К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> . –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI. Вот один из примеров: Помогите установить и настроить службу сертификации. Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка 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. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии. Двухуровневая иерархия выглядит крайне привлекательно:

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

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

Planning CA types

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

Характеризуются нетребовательностью к наличию домена 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). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на 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.

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

Вам также может понравиться

Windows или Linux: Что лучше выбрать?

Есть много причин выбирать между Windows и Linux, но

Файл владелец изменить linux

Команда Chown в Linux Chown Command in Linux (File

Установка шлюза по умолчанию linux

Настройка сети вручную Содержание Краткое описание

Чем разбить диск для linux

ИТ База знаний Курс по Asterisk Полезно — Узнать IP —