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

Примечание: перед проведением любых изменений, описываемых в этом посте, обязательно выполните бэкап.

Большинство администраторов при установки роли Active Directory Certificate Services (AD CS) делают очень просто Next –> Next –> ????? –> PROFIT. С одной стороны это и хорошо, но часто это не очень хорошо. Чем это хорошо — оно будет работать. Чем это плохо — при появлении каких-то специфических условий (например, внешние по отношению к текущему лесу клиенты) оно начинает работать хуже и даже перестаёт быть работоспособным. Сегодня я планирую рассмотреть эти вопросы, как нестанадртные клиенты (не поддерживающие LDAP) и внешние клиенты, тем более это достаточно распространённый сценарий.

Рекомендация 1 — CA и IIS

Самая первая рекомендация будет заключаться в том, что не надо устанавливать службу IIS на сервер CA (кроме случаев, когда у вас в сети всего один сервер). При установке роли AD CS мастер предлагает установить IIS для работы HTTP ссылок на CRT и CRL файлы. Я считаю, что при наличии внутреннего и/или внешнего веб-сервера устанавливать ещё один на сервер CA — затея глупая. Вы этим самым просто добавляете себе лишней работы и не решаете некоторых задач. Установка новой роли увеличивает площадь атаки для злоумышленников, отнимает время администраторов, повышает расходы на организацию защиты IIS и не решает вопрос обслуживания внешних клиентов, поскольку публикация сервера CA в интернет (хоть и только роли IIS. При успешной атаке роли можно получить контроль над всем сервером) идея настолько глупая и неудачная, что её рассматривать нет никакого желания. Я вообще считаю, что на сервере CA кроме роли CA ничего быть не должно. Поэтому при установке роли CA благоразумно отказываемся. Взамен этого мы будем использовать выделенный веб-сервер, который скорее всего установлен в вашей компании. При этом он может работать под управлением любой ОС, хоть линупса. Об этом будет написано чуть ниже.

Рекомендация 2 — CDP/AIA и LDAP

Мы уже рассматривали общую проблематику вопроса в одном из предыдущих постов: CRL Distribution Points и Authority Information Access. По причинам описанным в указанном посте мы хмуро выпиливаем все ссылки на LDAP.

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

Для этого запустите оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. В этой вкладке выделите ссылку, начинающуюся с LDAP://{тут_много_букв} и HTTP://{тут_много_букв} и нажмите кнопку Remove. Далее в выпадающем поле со списком выберите Authority Information Access (AIA), выделите ссылку, начинающуюся с LDAP://{тут_много_букв} и HTTP://{тут_много_букв} и нажмите кнопку Remove.

Этим шагом мы отменим использование LDAP ссылок, которые могут быть совершенно не пригодны для ряда типов клиентов, как мобильные клиенты, клиенты из интернета, клиенты рабочих групп, других лесов и т.д. А так же удалили дефолтные HTTP ссылки, которые указывают на сервер CA.

• Необходимые шаги для случаев, когда сервер CA уже выпустил сертификаты.

Для этого запустите оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. В этой вкладке выделите ссылку, начинающуюся с LDAP://{тут_много_букв}. Снимите все галочки, кроме Publish CRLs to this location и Publish Delta CRLs to this location (если вы планируете использовать Delta CRL). А так же удалите ссылки HTTP, которые указывают на сам сервер CA. Сохраните изменения и перезапустите службу Certificate Services.

Этим шагом мы отключили публикацию LDAP и HTTP ссылок во вновь издаваемые сертификаты. Однако, у нас уже работающая инфраструктура PKI, следовательно, ранее выпущенные сертификаты содержат ссылки на LDAP. Для обеспечения их работоспособности мы продолжаем публикацию CRT/CRL файлов в LDAP.

Отсебятина 1 — именование файлов

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

<ServerDNSName>_<CAName><CertificateName>.crt

Т.е. обычно это выглядит так: caserver.company.com_companyca.crt. Скажем, не всем нравится такой формат, поскольку имя файла достаточно длинное и раскрывает внутреннее имя сервера, на котором хостится служба CA. Лично мне нравится другой формат имён файлов — короткое имя компании и аббревиатурное значение роли конкретного сервера CA. Например: company_RCA.crt. Мне кажется, что это хороший выбор. Однако, ни стандартный интерфейс CertSrv.msc, ни реестр не предоставляют возможности изменять имя и путь публикации CRT файла. Учитывая, что сертификаты самих CA обновляются достаточно редко, эту операцию можно выполнить вручную или при помощи скрипта — это уже на ваш выбор. Так что с CRT ничего не остаётся как копировать его вручную на веб-сервер или гонять его по DFS и переименовывать самостоятельно. Однако, следует учесть, что если сертификат CA обновлялся с новой ключевой парой, в конце имени файла добавляется число в круглых скобках. Например: server.domain.com_CAName(1).crt. Вот эта циферка приходит из <CertificateName>. Именно поэтому когда вы будете имзенять ссылку (об этом чуть ниже), которая будет публиковаться в издаваемых сертификатах, не забудьте к имени файла добавить <CertificateName>.

То же самое будет касаться и CRL. В соответствии с параграфом § 3.2.5.1.6 спецификации протокола [MS-CSRA]:

1.When this method is invoked, the CA SHOULD create a new base and/or delta CRL for each CA key, as specified in the following steps 2, 3, 4, 5, 6, and 7. The type of CRL to create (base, delta, or both) for each CA key is determined as follows:<38>

The CA SHOULD create a new base CRL for each CA key.

If the CA has enabled delta CRLs, as indicated by a nonzero Config_Delta_CRL_Validity_Period value, the CA MUST create a new delta CRL in addition to a new base CRL, for each CA key.

If delta CRLs are currently disabled (Config_Delta_CRL_Validity_Period is 0) and were enabled previously (Previous_Delta_CRL_Validity_Period is not equal to zero), the CA MUST create a new delta CRL in addition to a new base CRL for each CA key.

отдельный CRL создаётся для каждой ключевой пары CA. Следовательно, в имени CRL файлов следует оставить значение <CRLNameSuffix>. Этим самым сервер CA при публикации CRL на это место установит версию сертификата, для которого публикуется CRL. Например: CAName(1).crl и CAName(1)+.crl (для Base и Delta CRL). Если сертификат CA ещё не обновлялся, <CRLNameSuffix> будет заменён на пустое значение.

 

Рекомендация 3 — публикация файлов на Web-сервер

• Prerequisites

На веб-сервере создайте папку с произвольным именем (например, с именем pki), в которой будут храниться наши файлы. Расшарьте эту папку и добавьте в неё права записи для учётной записи компьютера, на котором работает сервер CA. При этом учтите, что права необходимо отредактировать как на уровне NTFS Rights и Share Permissions. В принципе, права Create files/Write data вполне достаточно для данной задачи. В IIS в произвольном веб-узле создайте виртуальную директорию и в качестве пути к ней укажите папку, в которой хранятся CRT/CRL файлы.

• CDP

Поскольку мы будем публиковать файлы на выделенный веб-сервер, мы должны отредактировать расширения соответствующим образом. Запустите оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. Нажмите кнопку Add и в поле Location укажите путь вида:

file://\\WebServerName\pki\MyCRLNewName<CRLNameSuffix><DeltaCRLAllowed>.crl

Я выделил обязательную составляющую имени CRL файла. Остальное уже на ваш вкус. И установите чек-боксы на Publish CRLs to this location и Publish Delta CRLs to this location (если вы планируете использовать Delta CRL). Если Delta CRL на сервере CA использоваться не будет, <DeltaCRLAllowed> можно убрать совсем.

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

http://www.company.com/pki/MyCRLNewName<CRLNameSuffix><DeltaCRLAllowed>.crl

И проставьте галочки: Include in the CDP extensions of issued certificates и Include in CRLS. Clients use this to find Delta CRL Locations (если используется Delta CRL).

• AIA

То же самое сделать для расширения AIA, чтобы получить ссылку вида:

http://www.company.com/pki/MyCRTNewName<CertificateName>.crt

И поставить галочку напротив Include in the AIA extension of issued certificates. Как я уже говорил, не представляется возможным автоматически публиковать CRT в нестандартные локации, поэтому их придётся переименовать вручную.

Примечание: имена физических файлов должны быть идентичными имени в HTTP ссылке.

В принципе, в конечном итоге вы должны получить примерно такой вид ссылок и установленных галочек:

CDP — новая инсталляция

C:\WINDOWS\system32\CertSrv\CertEnroll\<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

file://\\WebServerName\pki\Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

http://www.company.com/pki/Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Include in the CDP extensions of issued certificates
Include in CRLS. Clients use this to find Delta CRL Locations

CDP — унаследованная инсталляция

C:\WINDOWS\system32\CertSrv\CertEnroll\<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

Примечание: не следует удалять этот путь, поскольку он используется самим сервером CA.

file://\\WebServerName\pki\Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

ldap:///CN=<CATruncatedName><CRLNameSuffix>, CN=<ServerShortName>, CN=CDP,CN=Public Key Services, CN=Services, <ConfigurationContainer><CAObjectClass>
Publish CRLs to this location
Publish Delta CRLs to this location

http://www.company.com/pki/Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Include in the CDP extensions of issued certificates
Include in CRLS. Clients use this to find Delta CRL Locations

AIA — новая и унаследованная инсталляции

C:\WINDOWS\system32\CertSrv\CertEnroll\<ServerDNSName>_<CAName><CertificateName>.crt
нет галочек. Остаётся без изменений.

http://www.company.com/pki/Company_RCA<CertificateName>.crt
Include in the AIA extension of issued certificates

Я не призываю сразу бросаться и всё переделывать. Эти рекомендации даны только для понимания сути проблемы и каким образом её можно решить. С их помощью при необходимости можно самостоятельно подготовить план изменения расширений CDP и AIA.

---