Я никому ещё не говорил об этом, но на последних скриптинг-геймсах в Event 3 я вышел победителем и мне полагалась книжка Windows PowerShell Scripting Guide с авторством и автографом главного скриптинг гайя — Эда Уилсона. К сожалению FedEx не смог найти мой адрес, чтобы доставить приз (хотя UPS почему-то может меня найти) и вернул посылку обратно. Поэтому я приготовил резервный план. Как многие знают, несколько недель назад в Берлине прошёл TechEd Europe 2009, на котором присутствовала и вся элита PowerShell'а. По различным причинам мне не удалось попасть на это мероприятие, поэтому пришлось командировать Васю Гусева с особо секретным, ответственным и невероятно опасным заданием — собрать для меня автографы самы-самых и самого Эда Уилсона. Но, как назло, его не было на техэде, зато был Джеффри Сновер!

Вобщем, Вася благополучно провалилёл операцию и доставил мне эту книжку с набором весьма ценных закорючек:

Сверху — Marc van Orsouw (он же /\/\o\/\/), чуть ниже и правее идёт Thomas Lee, внизу в центре у нас Вася Гусев, внизу слева Дима Сотников, а по самому центру — Джеффри Сновер. Собственно, вот

Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).

В сфере PKI OID'ы имеют очень важное значение, хоть это далеко и не всегда очевидно для администраторов. Что такое OID? Это Object IDentifier (OID), который является как бы древовидным «инвентаризационным» номером объекта. В инфраструктуре PKI этими OID'ами обладают очень много типов объектов, например:

• Шаблоны сертификатов;
• Application Policies/Extended Key Usages (EKU);
• Issuance Policies/Certificate Policies;
• Certificate Practice Statement;
• алгоритмы криптографии
• и т.д.

Как они выглядят? OID'ы записываются с использованием десятично-точечной нотации, например: 1.3.6.1.5.5.7.3.1. Поскольку OID'ы являются древовидной структурой, то каждый элемент имеет какое-то значение. Схема дерева достаточно обширна и отобразить её всю весьма проблемно. Но существуют ресурсы, которые позволяют исследовать деревья стандартизированных OID'ов. Чтобы показать сложность этого дерева можно попробовать разобрать вышеуказанный OID:

1 — ISO assigned
3 — ISO Identified Organization
6 — US Department of Defense
1 — Internet
5 — Security
5 — Mechanisms
7 — PKIX
3 — id-kp, arc for extended key purpose OIDS
1 — id_kp_serverAuth

Вот так пройдясь по дереву OID'ов мы выяснили, что этот OID обозначает Server Authentication в Application Policies/EKU сертификатов. Вы можете самостоятельно поупражняться в разборе OID'ов с использованием этой странички: OID assignments from the top node. В принципе, вы должны уметь ориентироваться в стандартизированных OID'ах, которые используются в интернете.

Но это всё теория. На практике случается, что этих стандартизированных OID'ов недостаточно, чтобы описать конкретный объект. Для этого IANA выделила специальную ветвь OID'ов для частных организаций, которые могут в пределах этой ветви создавать свои собственные OID'ы. Корнем этой ветви является: 1.3.6.1.4.1.xxx.yyy

где xxx — уникальный OID, который выделяется конкретной частной организации и yyy — прозивольное пространство OID'ов, которые закреплены за конкретной организацией. Например, компании Microsoft выделено пространство с OID = 311 или полный путь дерева 1.3.6.1.4.1.311. Как видно по этой ссылке, все OID'ы которые используются только в продуктах Microsoft используют ветку 1.3.6.1.4.1.311. Когда вы создаёте новый шаблон сертификатов, Issuance Policy, Application Policy, Windows генерирует рандомный OID который находится в ветке, которой владеет Microsoft. В принципе, это не так страшно до тех пор, пока ваша или партнёрская компания не станут использовать сертификаты друг друга. Вот тогда могут начаться проблемы с валидацией сертификатов. Рассмотрим ситуацию:

Вы — компания «Дизайн табуреток» по производству приложений для макетирования и моделирования табуреток и эти приложения используются у партнёрской организации «Табуретки для всех». Каждое ваше приложение подписано сертификатом подписи. В обеих компаниях существуют строгие правила проверки и выдачи сертификатов подписи. В компании «Дизайн табуреток» используется 2 шаблона сертификатов подписи:

• Internal Code signing;
• External Code Signing.

Сертификаты на основе первого шаблона выдаются разработчикам на основе автоматической выдачи сертификатов (autoenrollment) для внутренних нужд. Когда приложение уже готово для поставки производителям табуреток (например, «Табуретки для всех»), то приложение окончательно подписывается руководителем разработок приложения. Поскольку это очень ответственный процесс, вы создали шаблон сертификатов с названием External Code Signing, но с более строгими требованиями:

• Сертификат выдаётся только уполномоченным лицам, предварительно подписавших документ, который регулирует ответственность за подписываемые этим сертификатом файлы;
• Для выдачи сертификата требуется явное одобрение менеджера CA;
• Сертификат должен храниться только на смарт-карте (в криптопровайдерах шаблона указан CSP поставщика смарт-карт, например Aladdin);
• Сертификат выдаётся только теми CA, которые отвечают 2-му уровню безопасности (что подразумевает использование HSM, раздельное управление службами CA и т.д.).

Поскольку оба шаблона выпускают сертификаты с одинаковым Application Policy/EKU (OID = 1.3.6.1.5.5.7.3.3), для определения различных порядков выдачи сертификатов вы создали два отдельных Issuance Policy, InternalIssuance (OID = 1.3.6.1.4.1.311.8888.8888) и ExternalIssuance (OID = 1.3.6.1.4.1.311.9999.9999) и назначили каждую политику выдачи соответствующему шаблону.

Примечание: как я уже гоорил, эти OID'ы будут генерироваться рандомно, но в пределах ветки принадлежащей Microsoft. Если у вас есть своё пространство OID'ов, то при создании новой политики выдачи отредактируйте OID так, чтобы он находился в пространстве OID'ов вашей компании.

Компания «Табуретки для всех» удовлетворена мерами безопасности, которые предприняты разработчиком программ макетирования табуреток для охраны сертификата подписи и готова доверять таким сертификатам. Но в силу ряда причин, компания не хочет доверять остальным сертификатам выданных в компании «Дизайн табуреток». Следовательно будет организовываться частичное доверие, которое именуется как Cross-certification или Qualified Subordination.

Как быть в такой ситуации? Поскольку оба шаблона выдают сертификаты с одинаковым Application Policy, то Certificate Trust List (CTL) здесь не подходит. Для этого компания «Табуретки для всех» создаёт у себя файл policy.inf, который помимо всего прочего содержит вот такие строчки:

[ApplicationPolicyStatementExtension]
Policies = CodeSigning
critical = false

[CodeSigning]
OID = 1.3.6.1.5.5.7.3.3

[PolicyStatementExtension]
Policies = ExternalIssuance
Critical = false

[ExternalIssuance]
OID = 1.3.6.1.4.1.311.9999.9999

и с использованием этого файла policy.inf создали сертификат на основе шаблона Cross Certification Authority. Вот что будет в этом сертификате:

Данный CrossCA сертификат выдан в CA компании «Табуретки для всех» на имя выдающего (Issuing CA) CA в компании «Дизайн табуреток». И данный сертификат публикуется в компании «Табуретки для всех» посредством групповых политик или через AD.

Примечание: вопрос создания Cross Certification Authority выходит за рамки данной статьи. Хоть тема создания Cross CA весьма интересна, но, к сожалению, на практике используется не так часто, как сами сертификаты. Поэтому рассказывать об этом нет смысла, наверное.

Таким образом, компания «Табуретки для всех» будет доверять только тем сертификатам компании «Дизайн табуреток», в расширениях которых содержится как минимум:

• Certificate Policies –> Policy Identifier = 1.3.6.1.4.1.311.9999.9999
• Application Polocies –> Policy Identifier = Code Signing

Если любое из этих условий не выполняется, то «Табуретки для всех» не будут доверять таким сертификатам.

Как видите, OID'ы обретают особую важность когда ваши сертификаты начинают использоваться вне пределах вашей компании. Но здесь сразу возникает вопрос: а кто владеет OID = 1.3.6.1.4.1.311.9999.9999? Поскольку OID находится внутри ветки принадлежащей Microsoft, компания «Дизайн табуреток» по сути говоря ничего общего с этим OID'ом не имеет. Чтобы решить этот вопрос, как я уже говорил выше, каждая компания должна получить в IANA (или любой подобной организации) свой OID. В большинстве случаев это совершенно бесплатно (жадные дети могут радоваться ) и оформить его можно, например, вот по этой ссылке: http://pen.iana.org/pen/PenApplication.page

После выполнения всех формальностей и подтверждения вы получите своё OID-пространство. Например, у меня номер 34658 и все мои собственные OID'ы (как Application Policies, CPS, Issuance Policies, etc) будут храниться в этом дереве: 1.3.6.1.4.1.34658. Скажем, мой CPS будет иметь OID = 1.3.6.1.4.1.34658.1 или 1.3.6.1.4.1.34658.222. Вместо последней цифры может быть что угодно, что придёт мне на ум, поскольку не существует нормативных документов, которые бы регулировали использования пространства OID'ов. Но в качестве образца можно посмотреть, как это сделано в Microsoft: http://support.microsoft.com/kb/287547. Чтобы выяснить владельца того или оного пространства, можно пройти по ссылке: http://www.iana.org/assignments/enterprise-numbers.

Таким образом нестандартные OID'ы в инфраструктуре PKI следует использовать только в пространстве OID'ов, которые выданы для вашей организации (кроме шаблонов сертификатов, чьи OID'ы менять не следует). Этим самым устраняются проблемы вопросов владения и ответственности за использование и содержимое сертификатов. Но у нас на сегодня остаётся последний вопрос: а где мы должны публиковать используемые нами OID'ы и их описания? Как правило все OID'ы, которые могут использоваться внутри и вне пределах вашей организации описываются в документе под названием Certificate Practice Statement или сокращённо CPS.

Собственно всё, что я хотел сегодня поведать про OID'ы. Если кому-то будет интересно, то можно будет посмотреть эту тему чуть плотнее.

В продолжении темы исследования COM интерфейсов CryptoAPI для управления службами Certificate Services предлагаю теперь разобрать вопросы KRA — Key Recovery Agents. Сначала напомню уже изученные темы по CryptoAPI:

• CryptoAPI и управление Certification Authority с помощью PowerShell
• CryptoAPI и управление Certification Authority с помощью PowerShell (часть 2)
• CryptoAPI и управление Certification Authority с помощью PowerShell (часть 3)

И на сегодня наш план выглядит достаточно интересно:

• Получение списка доступных KRA в лесу и просмотр их сертификатов
• Получение списка KRA назначенных на сервере CA;
• Назначение новых KRA для CA.

Получение списка доступных KRA в лесу

KRA используется для архивирования закрытых ключей сертификатов в БД CA. В случае если пользователь уничтожил свой закрытый ключ он может его восстановить. Для этого нужно обратиться к администратору CA для извлечения BLOB (Binary Large OBject) в файл. После чего агент восстановления (KRA) использует свой закрытый ключ для расшифровки закрытого ключа из BLOB'а. Учитывая, что я и не только уже рассматривали этот вопрос, я не буду пересказывать принцип работы Key Archival:

• EFS и смарт-карты в Windows Server 2008 (часть 2)
• EFS и смарт-карты в Windows Server 2008 (часть 3)
• Understanding Key Archival

Все сертификаты KRA публикуются в forest naming configuration context партиции AD и реплицируется между всеми контроллерами в лесу. Публикация просисходит в точке:

CN=KRA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain

Мы получили список CA в лесу и посмотрев каждый из них можем посмотреть сколько KRA сертификатов выпустил каждый CA:

Свойство UserCertificate в виде массива может содержать сертификаты KRA в виде байтового массива. Например, указанный CA выпустил 2 сертификата KRA:

И обратившись к индексам этого свойства можно получить конкретные сертификаты: $kra[1].usercertificate[0]. Если CA не выпускал сертификаты для KRA, то свойство UserCertificate будет содержать число ноль:

Поэтому для получения всех сертификатов KRA нужно пройтись по всем членам CN=KRA и выбрать из них ненулевые значения свойства UserCertificate. Если сертификатов больше, чем 1, то они будут храниться в этом свойстве в виде массива. Чтобы посмотреть сам сертификат, вы можете просто сохранить этот массив байтов в файл:

Получение списка KRA назначенных на сервере CA

А теперь вернёмся к интерфейсу ICertAdmin2. С его помощью мы можем посмотреть количество агентов восстановления, которые назначены на CA и посмотреть их сертификаты. Однако, этот интерфейс имеет какой-то баг с PropID, которые связаны с KRA, о которых я писал в предыдущей статье, поэтому для получения этих данных мы будем использовать интерфейс ICertRequest3.

Мы видим, что на сервере DC1 назначен 1 агент восстановления, а на DC2 ни одного. Сегодня мы добавим агентов восстановления на DC2.

Примечание: чем отличаются KRACERTUSEDCOUNT и KRACERTCOUNT? KRACERTCOUNT показывает сколько всего KRA назначено на конкретном сервере CA. А KRACERTUSEDCOUNT показывает сколько из них будет использовать CA при архивации каждого закрытого ключа сертификата и это число может быть меньше, чем общее количество сертификатов KRA. В таком случае CA рандомно выбирает KRACERTUSEDCOUNT сертификатов и шифрует ими закрытый ключ. Например, KRACERTCOUNT = 5, а KRACERTUSEDCOUNT = 3, то CA при архивации ключа выберет рандомно 3 сертификата KRA из списка и зашифрует ими ключ. И только эти 3 агента восстановления могут восстановить ключ, а остальные 2 уже не смогут.

Получение списка KRA назначенных на сервере CA

Чтобы посмотреть сами сертификаты KRA, мы должны воспользоваться PropID = CR_PROP_KRACERT (0x1A).

И вот что мы увидим:

В нулевом индексе мы видим первый сертификат. Последующие будут храниться в других индексах:

$CertAdmin.GetCAProperty("dc1\contoso ca",0x1A,$Index,3,0)

Этот сертификат можно спокойно записать в файл и через GUI просмотреть его свойства. Но вообще это не родной формат сертификата KRA для данного интерфейса, поскольку добавлять сертификаты KRA на сервере CA нужно в ASN1 DER-encoded string формате. Т.е. Flags должен быть не 0, а 2:

$CertAdmin.GetCAProperty("dc1\contoso ca",0x1A,$Index,3,2)

и увидим примерно такое:

выглядит весьма уныло, но вот в таком формате и надо записывать сертификаты агентов восстановления в CA.

Назначение новых KRA для CA

Когда мы рассмотрели основные моменты связанные с агентами восстановления в контексте CryptoAPI, мы можем приступить к финальной части — назначению новых агентов восстановления. В принципе, здесь нет ничего сложного, поскольку для добавления KRA нужно сделать 5 вещи:

1. Получить массив байтов, которые бы представляли сертификат агента восстановления откуда угодно. Хоть из AD, хоть из файла сертификата;
2. Используя специальный конвертер, разобрать этот массив на пары байтов, сконвертировать эти пары в little-endian hex строку, получить десятичное представление этой hex-строки и получить итоговую символьную строку;
3. Записать эту строку используя метод SetCAProperty();
4. Задать новое количество используемых агентов восстановления;
5. Перезапустить службу CA.

Первый этап у нас уже пройден, поскольку у нас уже есть такой массив в AD. Если сертификата агента восстановления нет в AD, то можно его получить из файла:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import(".\desktop\kra.cer")
$bytes = $cert.RawData

и переменная $bytes будет содержать такой же байтовый массив.

А вот с конвертером чуть сложнее. Я не нашёл ни одного готового конвертера, который бы выполнял все шаги из пункта 2, поэтому я написал свой конвертер с блек-джеком и шлюхами:

function ConvertTo-DERstring ([byte[]]$bytes) {
    # создаём объект StringBuilder, который нам будет собирать конечную символьную строку
    $SB = New-Object System.Text.StringBuilder
    # преобразовываем каждый байт в его hex значение
    $bytes1 = $bytes | %{"{0:X2}" -f $_}
    # циклом перебираем каждую пару байт
    for ($n = 0; $n -lt $bytes1.count; $n = $n + 2) {
        # переставляем элементы пары местами, чтобы получить little-endian hex-строку
        # после чего получаем десятичное представление этой строки и получаем Unicode
        # символ, который соответствует этому десятичному значению.
        [void]$SB.Append([char](Invoke-Expression 0x$(($bytes1[$n+1]) + ($bytes1[$n]))))
    }
    $SB.ToString()
}

А дальше уже по накатанной дороге:

всё.

Update 05.12.2009: разработчики подтвердили баг в ICertAdmin2 интерфейсе. Проблема заключается в том, что после первого запроса указанных PropID они кешируются и при смене контекста конфигурации (Certification Authority), этот кеш не очищается.

Прежде чем продолжать исследование CryptoAPI COM интерфейсов, предлагаю посмотреть несколько полезных ссылок и поговорить о багах в интерфейсе ICertAdmin2.

При использовании интерфейса ICertAdmin2, ICertRequest2D (этот интерфейс мы ещё посмотрим в будущих постах) мы используем различные аргументы для получения свойст CA с использованием метода GetCAProerty(). И вот их где мы можем получить числовые значения этих аргументов:

• PropID и PropType — 3.2.1.4.3.2 ICertRequestD2::GetCAProperty (Opnum 7)
• Flags — EncodingType Enumeration

А теперь поговорим о багах. Как выяснилось, ICertAdmin2::GetCAProperty(), который определён в библиотеке certadm.dll имеет баги с PropID, которые связаны с количественной информацией. Будь то количество сертификатов CA, количество агентов восстановления ключей (Key Recovery Agents) и т.д. И вот в чём это выражается:

• DC1 — корневой CA с именем Contoso CA. Имеет 2 сертификата CA и одного назначенного агента восстановления;
• DC2 — подчинённый CA с именем Contoso-DC2-CA. Имеет 1 сертификат CA и ни одного назначенного агента восстановления.

Мы будем получать данные как с локального CA, так и с удалённого CA запуская код с каждого сервера. Кратко об используемых PropID:

• 0x0B — количество сертификатов CA;
• 0x19 — общее количество агентов восстановления на CA;
• 0x18 — общее количество используемых агентов восстановления;

И вот какие результаты мы видим, когда собираем эти свойства с сервера DC1:

собираем ту же информацию, запуская код с сервера DC2:

а теперь посмотрим на результаты с использованием того же метода и тех же PropID, но с использованием интерфейса ICertRequest, который определён в библиотеке certcli.dll. Те же тесты уже возвращают правильные результаты:

с DC1:

с DC2:

Поэтому следует с осторожностью относиться к выводу ICertAdmin2::GetCAProperty(), а ещё лучше — использовать этот метод, который реализован в интерфейсе ICertRequest::GetCAProperty(). Чем это вызвано я пока не знаю, но задал я задал вопрос нужным людям, поэтому я дам знать в случае ответа на вопрос.

Сегодня первый и последний раз нарушаю негласное правило своего блога — не более одного поста в день. А дело в том, что я совсем забыл о том, что вчера этому блогу исполнялся ровно год. Мне кажется, что за этот год я донёс до своих читателей достаточно много актуальной и полезной информации и вам есть чему поучиться на этих материалах. Статистики как таковой я не веду, только руководствуюсь сведениями своего любимого Clustrmaps. И судя по его показаниям посещаемость блога выросла с 30-40 человек в день до 80-100, т.е. примерно в 2,5 раза, что не может не радовать , так что я двигаюсь явно в нужном направлении. Очень хочется надеяться, что это не первый день рождения моего бложика и он будет продолжать оставаться для меня кешем моего мозга. Вобщем,

С днём рождения, бложик!

В первой части управления Certification Authority (CA) мы рассмотрели метод GetCAProperty, при помощи которого мы можем получать различные сведения про сервер CA. Сегодня мы посмотрим ещё несколько интересных моментов, которые будут связаны с CRL и опять будет немного треша с CryptoAPI, а именно:

• Получение статуса публикации CRL;
• Получение Base и Delta CRL из CA в виде файлов;
• Отзыв сертификатов;
• Извлечение сертификатов из CRL;
• Публикация новых CRL.

Начало работы

Для начала мы должны будем создать ICertAdmin2 COM объект для управления CA, который будет использоваться нами для всех сегодняшних операций:

Получение Base и Delta CRL из CA в виде файлов

Далее мы должны узнать PropID, который бы отвечал за показ CRL вот по этой ссылке: 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7). Нас будет интересовать 2 этих ID: CR_PROP_BASECRL (0x11) и CR_PROP_DELTACRL (0x12). Поскольку тип возвращаемых данных будет Binary, то PropType будет равен 3, а Flags выставим в 0 (Base64CRLHeader). Можно и другой указать, от этого только зависит метод записи в файл.

Примечание: напоминаю, что индекс PropType начинается с 1, а Flags с 0 и их возможные значения описаны здесь: GetCAProperty. А так же то, что в Flags первые 2 значения перепутаны местами на MSDN.

И вот как мы их можем получить:

последние 2 команды просто запускают эти CRL файлы. К сожалению не существует ни одного родного класса, который бы представлял собой объект CRL, поэтому как-то разбирать его на таком уровне пока не представляется возможным. Хотя существуют сторонние библиотеки (например, в Mono есть класс X509CRL).

Получение статуса публикации CRL

Но мы можем кое что узнать о статусе наших CRL. Для этого существует PropID = CR_PROP_CRLSTATE (0x14). Тип возвращаемых данных будет Long, значит PropType будет 1, а Flags будет игнорироваться, поэтому поставим его в 0:

Расшифровку этого значения можно найти здесь:  3.2.1.4.2.2.20 PropID = 0x00000014 (CR_PROP_CRLSTATE) "CA CRL State". Число 3 означает, что с CRL у нас всё хорошо (CA_DISP_VALID (0x03)). В принципе, на данном этапе нам больше ничего и не нужно. Но мы можем посмотреть более детальные сведения по каждому типу CRL. Для получения более детальной ошибки мы должны использовать следующие PropID:

• CR_PROP_BASECRLPUBLISHSTATUS (0x1E)
• CR_PROP_DELTACRLPUBLISHSTATUS (0x1F)

Для этих PropID тип данных так же указан Long, поэтому PropType выставим в 1, а Flags в 0:

Мы получили число 5 для BaseCRL и 6 для DeltaCRL. Расшифровку этих значений можно посмотреть вот здесь: 3.2.1.4.2.2.30 PropID = 0x0000001E (CR_PROP_BASECRLPUBLISHSTATUS) "Base CRL Publishing Status". Поскольку вывод — не конкретное число, а результат двоичного оператора И (AND), то мы это число должны разбить на составляющие. И вот как это делается:

$Return = $certadmin.GetCAProperty("ServerName\CA Name",0x1E,0,1,0)
$options = 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 | %{$Return -band $_} | ?{$_}
# поскольку значения масок являются результаты возведения двойки в степень
# начиная от 0 до 11, то эту строчку можно переписать более готично.
# Напоминаю, что возведение любого числа в нулевую степень
# всегда вернёт 1. Кажется, это из алгебры 5-6 класса.
$options = 0..11| %{[Math]::Pow(2,$_)} | %{$Return -band $_} | ?{$_}
switch ($options) {
    1 {"The CRL is a base CRL"}
    2 {"The CRL is a delta CRL"}
    4 {"The last CRL publication that was completed and published to the locations specified in the CA"}
    8 {"The CRL is a shadow delta CRL"}
    16 {"The CA MAY publish the CRL to a local store that is not externally accessible.
        This error is returned when publishing to this intermediate store failed"}
    32 {"An error occurred during publication of the CRL.
        The error indicates that the file schema cannot be recognized.The schema must be file: or ldap:"}
    64 {"Publication of the CRL was manually initiated by an administrator"}
    128 {"A CRL signature error was detected. The CSP was not correct"}
    256 {"An error occurred during publication of the CRL to an LDAP URL"}
    512 {"An error occurred during publication of the CRL to a file URL"}
    1024 {"An error occurred during publication of the CRL to an FTP URL. FTP URLs are not supported"}
    2048 {"The CA cannot publish CRLs to HTTP URLs. This error is returned if a CA administrator
        configured the CA to publish CRLs to HTTP URLs"}
}

Следовательно число 5 (1+4) говорит нам о том, что это был Base CRL и он был опубликован успешно. А 6 (2+4) — Delta CRL был опубликован успешно.

Отзыв сертификатов

Интерфейс IcertAdmin2 позволяет нам отзывать сертификаты на сервере CA. Для этого мы воспользуемся методом RevokeCertificate(). Метод достаточно простой и примерная команда для отзыва сертификата будет выглядеть так:

$CertAdmin.RevokeCertificate("ServerName\CA Name", 0123456789,4,(Get-Date).AddDays(1))

0123456789 будет обозначать серийный номер сертификата, 4 — причина отзыва будет Superseded и эффективная дата отзыва (когда сертификат будет помещён в Revoked Certificates) будет 24 часа после выполнения команды. Да, именно этим методом можно отзывать корневые сертификаты .

Извлечение сертификатов из CRL

Примечание: хоть Microsoft и поддерживает извлечение сертификатов из CRL (отмена статуса Revoked), этой возможностью не следует пользоваться в силу определённых причин, как невозможность определеления в какое время сертификат был помещён и извлечён из CRL.

Если сертификат был отозван со статусом Certificate Hold (6), то его можно в любое время вернуть обратно. Для всех остальных типов отзыва такая возможность не поддерживается. Для отмены статуса Revoked нужно использовать этот же метод, только в качестве причины отзыва указать значение MAX_DWORD, которое является 0xffffffff или просто –1:

$CertAdmin.RevokeCertificate("ServerName\CA Name", 0123456789,-1,0)

Публикация новых CRL

Если вы хотите опубликовать новые CRL вручную (т.е. в промежутке между плановой публикацией CRL), то мы должны воспользоваться методом PublishCRLs(). Его синтаксис достаточно простой:

$CertAdmin.PublishCRLs("ServerName\CA Name",0,0)

Эта команда переопубликует как основной, так и инкрементальный CRL (при публикации Base CRL инкрементальный CRL публикуется всегда, потому что Effective Date у него не может быть меньше, чем у Base CRL). Что касается последнего аргумента, то он бывает ещё полезен, если по каким-то причинам потерялся какой-то файл CRL. Тогда вы можете выставить CRLFlags в 4 (0x4) и тогда CA переопубликует текущие CRL без обновления их содержимого и дат.

На сегодня это всё.

Disclaimer: данный материал публикуется исключительно в учебных целях и его НЕ следует повторять! Любые действия описанные в данной статье вы можете делать ТОЛЬКО на свой страх и риск.

Мы с вами уже достаточно много обсудили про certificate chaining engine и расширения CDP в сертификатах и связанные с ними вопросы:

• Certificate Chaining Engine — как это работает
• Certificate chaining engine в PowerShell
• Certificate chaining engine в PowerShell (часть 2)
• CRL Distribution Points и Authority Information Access

Но я решил немного расширить сознание по этому вопросу и рассмотреть ситуацию с отозванным корневым (который является и самоподписанным) сертификатом. Для экспериментов использовались CA под управлением Windows Server 2003 и Windows Server 2008 R2 (в обоих случаях поведение было идентичное). Штатно (из консоли certsrv.msc) у нас нет возможности отозвать корневой сертификат CA, но мы можем технически это сделать с использованием CryptoAPI COM интерфейсов. Сразу после отзыва корневого сертификата в свойствах CA мы увидим вот такую картинку:

и вот такое сообщение в журнале событий:

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          2009.11.08. 17:35:44
Event ID:      51
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      RootCA
Description:
A certificate in the chain for CA certificate 0 for Adatum CA has been revoked.  The certificate is revoked. 0x80092010 (-2146885616).

Всё, приехали, что дальше? А дальше мы рассмотрим актуальность наличия CDP в корневых сертификатах, при помощи которых мы можем посмотреть CRL рассматриваемого CA (это корневой CA, поэтому в его CDP могут быть ссылки только на его собственный CRL), как это делают некоторые публичные коммерческие CA (например, StartCom). Когда корневой сертификат отозван, мы продолжаем его не наблюдать в консоли certsrv.msc, но в БД это хорошо видно:

Request Status Code: 0x0 (WIN32: 0) -- The operation completed successfully.
Request Disposition: 0xf (15) -- CA Cert
Request Disposition Message: "Revoked by ADATUM\Administrator"
Request Submission Date: 2009.11.07. 22:41
Request Resolution Date: 2009.11.07. 22:41
Revocation Date: 2009.11.08. 17:35:43
Effective Revocation Date: 2009.11.08. 17:35:43
Revocation Reason: 0x0 -- Reason: Unspecified

Но мы же можем попробовать опубликовать новый CRL? Ответ — нет, не можете. Поскольку CRL подписывается закрытым ключом CA, то перед подписью CRL производится проверка валидности этого ключа для подписи CRL. Т.к. на данном этапе CA уже знает, что сертификат отозван, то ключ блокируется для подписи новых CRL, т.к. они будут считаться поддельными. Это будет первый аргумент в пользу отсутствия CDP в корневых сертификатах. Если CRL подписан отозванным ключом, то этот CRL должен игнорироваться по очевидным причинам.

Однако, тут есть одна интересная вещь — пока служба CertSvc не перезапущена, мы можем энролить новые сертификаты. Т.е. в этом промежутке клиенты могут нагенерить запросы и получить в ответ сертификаты. Это действительно проблема, потому что сертификаты так же подписываются закрытым ключом CA. И, по всей видимости, CA лишь с некоторой периодичностью проверяет валидность закрытого ключа для данной операции. Хотя, в случае с CRL эта проверка производится каждый раз перед подписью. После остановки службы CertSvc наш CA отключается навсегда:

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          2009.11.08. 17:42:21
Event ID:      100
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      RootCA
Description:
Active Directory Certificate Services did not start: Could not load or verify the current CA certificate.  Adatum CA The certificate is revoked. 0x80092010 (-2146885616).

А дальше становится ещё интересней. Методика работы CCE описана в RFC3280. Для администраторов PKI описываемый там материал нужно знать обязательно. Параграф 6 описывает процедуру построения цепочки сертификатов:

§ 6.1.

When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path

Это означает, что самоподписанный сертификат (корневой таковым и является) исключается из проспективной цепочки сертификатов. А проверка CRL допускается только для этой проспективной цепочки.

§ 6.1.1.

The trusted anchor information is trusted because it was delivered
to the path processing procedure by some trustworthy out-of-band
procedure.

§ 9.

The certification path validation algorithm depends on the certain
knowledge of the public keys (and other information) about one or
more trusted CAs. The decision to trust a CA is an important
decision as it ultimately determines the trust afforded a
certificate.

Иными словами RFC предусматривает безоговорочное доверие конкретному корневому сертификату, когда доверие осуществляется каким-то механизмом (в Windows это наличие сертификата в Trusted Root CAs). И в § 6.1.3 говорится, что из цепочки (проспективной) удаляются все самоподписанные сертификаты, следовательно произвести проверку CRL можно только для сертификатов, которые в цепочке находятся на уровень ниже, чем самоподписанный сертификат. Это означает только одну вещь: если CCE является RFC3280-compliant, то он должен игнорировать расширение CDP в самоподписанном сертификате. Учитывая, что Windows CA технически не позволяет поместить свой сертификат в свой CRL, то скорее всего реализация CCE в CryptoAPI будет дейтсвовать адекватно и во всех случаях игнорировать это расширение. Поэтому даже при гипотетической возможности помещения отозванного корневого сертификата в его собственный CRL мы проигнорируем такой CRL и не узнаем, что корневой сертификат ВНЕЗАПНО был отозван.

Это была реклама VeriSign.

Продолжая тему криптографии, предлагаю несколько ближайших постов посвятить вопросам использования CryptoAPI в PowerShell для управления Cerficiation Authority (сокращённо CA). Я считаю эту тему достаточно интересной, хоть у нас есть космическая утилита certutil.exe. Но тот, кто видел хелп к нему, тот знает какой это ужас, автоматизировать что-то с использованием certutil. Microsoft подарил нам не менее космический и православный инструмент автоматизации — PowerShell. К сожалению, вынужден признать, что в ряде задач PowerShell сильно уступает аналогам в cmd и с этим ничего нельзя поделать. Но по мере своих сил буду пытаться доказывать обратное. Одно из преимуществ PowerShell является поддержка .NET, который очень удобен в использовании. Но .NET не всемогущ и не содержит в себе ни единого класса, при помощи которого можно было бы управлять службой certificate services (точнее самим CA). CryptoAPI неплохо документированы на уровне unmanaged code (а это подразумевает использование низкоуровневых языков программирования, как C++). Но, опять, слава сиськамСноверуПротоколу у нас есть одна лазейка — COM интерфейсы к CryptoAPI. Изучив немного эти интерфейсы, обнаружил, что они местами очень интересные и досточно легко управляемы. Но это не всегда так, иногда они бывают достаточно сложными для понимания с первого раза. В процессе исследования, были обнаружены вообще нелогичные вещи, с которыми нам придётся считаться.

Эти COM интерфейсы позволили мне реализовать едва ли не половину функционала моего PowerPack'а для PowerGUI. Оценить моё детище можно по этой ссылке: Enterprise PKI management. Я в него вложил достаточно много знаний для того, чтобы упростить жизнь администраторам инфраструктур PKI. Пока прогресс неважный, т.к. я пока только повторяю функционал консолей certmgr.msc, certsrv.msc, ocsp.msc и certutil.exe. Но я надеюсь реализовать там действительно что-то нужное и очень полезное.

Наша отправная точка на MSDN будет находиться здесь: Cryptography Interfaces. Для начала мы поработаем с интерфейсом ICertAdmin2, который зарегистрирован в системе как COM класс CertificateAuthority.Admin.1. Вот как он создаётся:

Как вы видите, этот интерфейс позволяет использовать достаточно много интересных методов. Давайте начнём с простого (а может быть и не очень простого) — GetCAProperty. По ссылке вообще ничего непонятно, что и как там использовать. Единственное, что я понял — это то, что данный метод принимает 5 параметров в определённом порядке и всё. Поэтому давайте будем считать, что этой странички не существует в природе (кроме случаев, когда будем преследовать порядок расположения аргументов). Пошарившись на MSDN, нашёл более годную ссылку в спецификациях Windows Communications Protocols — 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7). И вот как должны выглядеть параметры:

• strConfig — имя компьютера и сервера CA в формате ComputerName\CAName.
• PropId — ID требуемого свойства. Должно указываться в числовом формате (т.к. тип данных указан Long). Это число можно взять из колонки Numerical Value таблички 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7). Например, для получения DeltaCRL надо указать число 18 (0x12).
• PropIndex — если свойство индексированное (т.е. содержит несколько искомых объектов), то PropIndex указывает на индекс массива, в котором хранится определённый объект искомого свойства. Например, CA может содержать несколько своих сертификатов. И с использованием PropIndex мы сможем выбирать различные сертификаты, выбирая их из массива. Начало индексирования начинается с нуля. Если свойство неиндексируемое, то это значение будет игнорироваться.
• PropType — указываете тип данных, в котором хотите получить конкретное свойство. Во второй таблице уже указаны рекомендованные значения типов данных для каждого набора свойств. Тип данных так же нужно указывать в числовом формате. Однако, здесь индекс начинается не с нуля, а с единицы. Т.е. тип данных String будет иметь значение 4.
• Flags — помимо типа возвращаемых данных нам нужно указать формат этих данных. Во второй таблице так же приведены рекомендованные (хотя слово MUST и ещё капсом как бы намекает на обязательность. Хотя, это не совсем так. Если вы в первый раз будете этим заниматься, то используйте значения из второй таблички). А вот здесь индекс начинается с нуля.

Примечание: по всей видимости в табличке с флагами закралась ошибка, т.к. использование первого флага даёт Base64, но с заголовками Begin/End Certificate. А второй — наоборот, без заголовка.

Вам кажется, что это всё ужасно и сложно? Поверьте, это не так. Давайте прочитаем парочку свойств. Например, прочитаем ссылки на CRL и CRT, которые публикуются в CDP и AIA издаваемых сертификатах. Исходя из таблички мы знаем, что CRL'ы вызываются PropID = 0x29 (или 41 в десятичной нотации), а CRT — PropID = 0x2A (или 42). Поскольку это индексируемое свойство, то первая ссылка будет содержаться в индексе 0 (первый индекс массива), а последующие ссылки в индексах 1 и далее и PropIndex мы укажем 0. PropType у нас будет String и числовое значение — 4 (не забываем, что PropType считаются начиная с единицы). Flags может быть любой, т.к. он будет игнорироваться при PropType = 4:

Как вы видите, на самом деле здесь нет ничего страшного. Нужно лишь научиться оперировать табличкой. Давайте для разнообразия посмотрим на сертификат CA. Для этого мы должны найти PropID, который отвечал за сертификат. Это будет PropID = 0xC. Поскольку этот параметр так же индексируемый, то он будет содержать все сертификаты CA, если их там несколько. Самый первый сертификат будет храниться в индексе 0, следующий сертификат в индексе 1 и т.д. Исходя из таблички, PropType должен быть 3. Посмотрим сертификат в Base64 кодировке, т.е. Flags должен быть 0 или 1:

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

$CertAdmin.GetCAProperty("ServerName\CA Name", 0xC, 1, 3, 0)

Я просто увеличил PropIndex на единицу. Чтобы узнать сколько же там всего сертификатов, достаточно посмотреть PropID = 0x0B, PropType = 1 (т.к. команда нам вернёт число, то тип должен быть числовой — Long):

Вот в данном случае у меня там всего 1 сертификат. На другом сервере у меня 2 сертификата:

Если вам это интересно, то советую поупражняться в получении различных свойств в различном формате с использованием ICertAdmin2 интерфейса и таблички: 3.2.1.4.2.2 ICertRequestD2::GetCAProperty (Opnum 7).

Это была первая часть использования CryptoAPI в PowerShell. В следующих частях мы рассмотрим другие интересные методы интерфейса ICertAdmin2.

Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).

Большинство системных администраторов считают, что планирование списков отзыва сертификатов (Certificate Revocation List — CRL) и файлов сертификатов самих серверов CA — это элементарная вещь. Но практика показывает, что очень многие из них сильно заблуждаются. Поэтому предлагаю немного повременить с CryptoAPI и поговорить о немного более насущных вещах — рекомендации по планированию публикации списков CRL и сертификатов CA (Certification Authority), которые используются certificate chaining engine для построения и проверок цепочек сертификатов. О том, как работает этот движок можете почитать пост: Certificate Chaining Engine — как это работает.

Куда и как публиковать файлы CRL и CRT?

Как известно, каждый выданный в CA сертификат (кроме самоподписанных сертификатов. Корневой сертификат так же является самоподписанным сертификатом) содержит 2 расширения:

1. В расширении «CRL Distribution Points (CDP)» хранятся ссылки на CRL издавшего конкретный сертификат CA;
2. В расширении «Authority Information Access (AIA)» хранятся ссылки на сертификат CA, издавшего конкретный сертификат. А для сертификатов, выданных CA под управлением Windows Server 2008 и выше — могут содержаться ссылки на OCSP Responder (см. OCSP (часть 1) и OCSP (часть 2))

Эти ссылки берутся не из воздуха, а из настроек CA. Вот как они выглядят для дефолтной инсталляции Certificate Services:

 

В принципе, эти настройки годятся для нормальной работы certificate chaining engine в небольших сетях с одним лесом и доменом без сайтов (или с сайтами, соединённых быстрыми каналами). Если сеть состоит из нескольких доменов (или лесов с настроенным Cross-forest enrollment) и сайтами, соединённых не очень быстрыми каналами, то эти настройки уже могут приводить к сбоям построения и проверок цепочек сертификатов. Я не буду рассказывать, что означают галочки, т.к. с ними вы можете ознакомиться в статьях CRL Publishing Properties и AIA Publishing Properties, а приступлю сразу к разбору путей.

Первый путь указывает путь файловой системы, куда физически публикуются файлы CRL и CRT. Следующая ссылка (LDAP://{LDAP path}) указывает, точку публикации CRL и CRT в Active Directory. Так же эти пути будут прописаны во всех выдаваемых сертификатах. Третья ссылка (HTTP://{URL}) указывает URL, по которому клиенты могут скачать файл через HTTP и этот URL будет включён в расширение CDP/AIA всех выдаваемых сертификатов. Последняя ссылка ничего не делает и добавлена в целях дополнительной точки публикации файлов CRL/CRT в сетевой папке. Почему эти настройки не оптимальны для больших сетей?

Вот как будут выглядеть расширения CDP и AIA в выдаваемых сертификатах при таких настройках:

• CDP

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:   
  URL=ldap:///CN=Contoso%20CA,CN=DC1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
               URL=http://dc1.contoso.com/CertEnroll/Contoso%20CA.crl

• AIA

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:   
  URL=ldap:///CN=Contoso%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?base?objectClass=certificationAuthority
[2]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://dc1.contoso.com/CertEnroll/DC1.contoso.com_Contoso%20CA.crt

Как вы видите, ссылки в расширениях расположены в том же порядке, что и в настройках CA.

Это важно знать, поскольку certificate chaining engine (сокращённо назовём его CCE) будет проверять ссылки в том порядке, в котором они приведены в расширениях сертификата. Т.е. сперва будет пробовать скачать файл из Active Directory в течении 10 секунд. Если за 10 секунд файл не скачается, CCE будет пытаться скачать указанный файл по следующей ссылке (HTTP). При этом времени на это будет отводиться в 2 раза меньше (т.е. 5 секунд), чем в предыдущей попытке. И так будет происходить с каждой последующей ссылкой, пока не будет добыт файл, закончатся ссылки или отвалится по таймауту. На обработку каждого расширения для CCE выделяется ровно 20 секунд.

Уже на данном этапе видно, что любой недоменный клиент (будь то смартфон, изолированная рабочая станция в интернете, etc.) при попытке скачать файл может терять до 10 секунд на обработку первой ссылки, которая всегда завершится неудачей. Следовательно, первой ссылкой в CDP/AIA должна быть ссылка, которая использует универсальный для всех протокол (это должен быть HTTP), не смотря на то, что в домене, где расположен CA доступ через LDAP будет чуточку быстрее.

Второй момент заключается в репликации объектов AD. После того как CRL/CRT были опубликованы в Active Directory, клиенты об этом узнают не сразу, т.к. здесь вступает фактор репликации AD. Поскольку все объекты PKI публикуются в AD в разделе forest naming context, то эти данные реплицируются не только в прелелах текущего домена, но и всего леса. Поэтому задержки в появлении новых файлов у клиентов могут быть очень значительными и достигать нескольких часов. Задержки могут составлять время до двух полных циклов полной репликации в лесу. А если у вас используется cross-forest enrollment, то там ситуация будет ещё хуже, поскольку это ещё будет зависить от периодичности репликации объектов PKI между лесами (AD не поддерживает репликацию между лесами и репликация объектов PKI выполняется вручную) и уже может достигать нескольких суток. По этой причине рекомендуется либо вовсе отказаться от публикации CRL/CRT в AD и включения этих ссылок в сертификаты, либо располагать следом за более доступными протоколами.

С HTTP тоже не всё так идеально, как это может показаться с первого взгляда. Совсем не обязательно, чтобы сервер CA выполнял и роль веб-сервера (хотя, только для внутреннего использования это допустимо с определёнными оговорками). Будет лучше даже если файлы CRL/CRT будут копироваться как на внутренний, так и на внешний веб-серверы. В идеале эти файлы должны копироваться как минимум на 1-2 внутренних и 1-2 внешних веб-сервера для обеспечения высокой доступности. В таких случаях уже используется 4-я ссылка в настройках CA, которая должна указываь на шару DFS, чтобы файлы автоматически распространялись по веб-серверам. И вот здесь мы снова сталкиваемся с латентностью репликации DFS между серверами. Если все схемы публикации CRL/CRT подвержены латентности репликации, то как с этим бороться, чтобы файлы были всегда в актуальном состоянии?

Примечание: хоть CCE поддерживает скачивание CRL и CRT с HTTPS ссылок, делать это категорически нельзя, иначе CCE свалится в бесконечный цикл проверки сертификатов.

Периодичность публикации и обновления файлов CRL и CRT

По умолчанию в Windows Server основные CRL (Base CRL) публикуются раз в неделю и инкрементные CRL (Delta CRL) публикуются раз в сутки. Файлы сертификатов CA обычно обновляются через промежутки равные времени жизни сертификата самого CA (или чаще, если сертификат CA обновляется внепланово). Если сертификаты CA нужно обновлять достаточно редко (раз в несколько лет) и к этому следует готовиться отдельно, то обновление CRL происходит автоматически без вмешательства администратора и здесь требуются особые корректировки о которых мы сейчас и поговорим.

Если посмотреть на CRL, то мы увидим следующее:

 

Сейчас нас будут интересовать только 3 поля:

• Effective Date — указывает дату и время с которого данный CRL считается действительным и оно по умолчанию на 10 минут меньше, чем фактическое время, чтобы покрыть издержки рассинхронизации времени между сервером и клиентом;
• Next Update — указывает дату и время, когда заканчивается срок действия конкретного CRL и он считается недействительным;
• Next CRL Publish — указывает дату и время публикации следующего списка CRL.

Примечение: время в этих полях указывается в формате UTC без учёта временных зон.

Обычно время Next Update и Next CRL Publish одинаково. Но у меня, как вы видите на картинках, Next Update равен 8 дням (дефолтный срок действия CRL), а вот Next CRL Publish равен 7 дням после начала действия CRL. Т.е. CRL обновляется каждые 7 дней, но срок действия равен 8 дням (период публикации CRL + время overlap). Это сделано как раз для покрытия расходов времени (издержки репликации) распространения списков отозванных сертификатов от сервера CA до точек, откуда клиенты будут скачивать CRL. Как это делается?

Для этого в реестре на сервере CA по пути HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\CA Name существует 4 ключа:

• CRLOverlapUnits — указывает время до истечения срока действия текущего основного CRL, за которое будет публиковаться новый основной CRL.
• CRLOverlapPeriod — указывает единицу измерения этого времени для основного CRL
• CRLDeltaOverlapUnits — указывает время до истечения срока действия текущего инкрементального (если используется) CRL, за которое будет публиковаться новый инкрементальный CRL
• CRLDeltaPeriodPeriod — указывает единицу измерения этого времени для инкрементального CRL.

Если вы используете LDAP ссылки в расширениях CDP/AIA сертификатов и/или у вас есть латентность репликации файлов между веб-серверами, то вы должны отрегулировать это время, которое должно быть не менее, чем максимальное время репликации каталога AD во всём лесу или DFS как для основных, так и для инкрементальных CRL (если они у вас используются). Данную операцию можно автоматизировать утилитой certutil:

certutil –setreg ca\CRLOverlapUnits 1
certutil –setreg ca\CRLOverlapPeriod "days"
certutil –setreg ca\CRLDeltaOverlapUnits 8
certutil –setreg ca\CRLDeltaOverlapPeriod "hours"
net stop certsvc & net start certsvc

Примечание: CRLOverlap не может быть больше периодичности публикации BaseCRL, а CRLDeltaOverlap не может быть больше 12 часов.

в результате новые основные CRL будут публиковаться за сутки до истечения времени действия предыдущего основного CRL и новые инкрементальные CRL будут публиковаться за 8 часов до истечения предыдущего. Этим самым вы сможете гарантировать, что клиенты всегда получат актуальные CRL'ы. Более детальные сведения о порядке подсчёта временных интервалов публикации CRL и срока их действия можно ознакомиться здесь: How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated

Общая периодичность публикации самих файлов CRL зависит от количества отзываемых сертификатов за некоторый промежуток времени (обычно измеряется в неделях). Если сертификаты отзываются десятками в неделю, то есть смысл сократить периодичность публикации основных CRL до 2 раз в неделю и Delta CRL до 2-х раз в сутки. Если сертификаты отзываются редко (реже, чем раз в неделю), то периодичность публикации Base CRL можно увеличить до 2-4 недель, а от Delta CRL можно даже отказаться или публиковать раз в неделю. Но это касается только Issuing или Online CA. Для Offline CA рекомендации будут чуть другие. Поскольку Offline CA выдают сертификаты только другим CA и большую часть времени выключены, для них следует отключить публикацию Delta CRL (установив параметр CRLDeltaPeriodUnits в ноль), а основные CRL публиковать раз в 3-12 месяцев. Хоть это и Offline CA, но на него так же распространяются требования по корректировке времени публикации и срока действия CRL.

CDP и AIA в корневых сертификатах

Как уже отмечалось, расширения CDP и AIA содержат ссылки на CRL/CRT издавшего конкретный сертификат CA, то с корневыми сертификатами будет немного иначе. Если быть точнее, то в корневых сертификатах этих расширений быть не должно совсем. Почему? Windows Server 2003 по умолчанию добавлял эти расширения в самоподписанный сертификат, когда CA конфигурировался как корневой CA. В нём AIA содержал ссылки по которым можно было скачать этот же сертификат. Очень прикольно .

А CDP — не менее прикольно. Корневые сертификаты всегдя являются конечной точкой самой цепочки и доверия этой цепочки сертификатов. К корневым сертификатам доверие всегда устанавливается явное путём помещения сертификата в контейнер Trusted Root CAs (а ко всем остальным сертификатам устанавливается неявное доверие через цепочку сертификатов). Следовательно отменить доверие корневому сертификату CA можно только одним способом — удалить сам сертификат из контейнера Trusted Root CAs и никак иначе. Вторая проблема заключается в том, что все CRL подписываются закрытым ключом самого CA. А теперь предположим, что CA отозвал свой сертификат и поместил его в CRL. Клиент скачивает CRL и видит, что сертификат CA отозван. Можно предположить, что это всё и никакой проблемы здесь нет. Однако, получается, что CRL подписан отозванным сертификатом и мы не можем доверять этому CRL как и считать сертификат CA отозванным. Именно поэтому начиная с Windows Server 2008 при установке корневого CA, эти расширения по умолчанию уже не включены в корневой сертификат. А для Windows Server 2003 приходилось лепить костыли в файле CAPolicy.inf:

[AuthorityInformationAccess]
Empty = true
[CRLDistributionPoint]
Empty = true

Как показывает практика, очень много администраторов игнорируют такие вещи и делают всё простым Next-Next, за что они должны гореть в аду. Но не только простые Windows-админстраторы, а луноходы (фаны линукса) тоже должны там гореть. Как живой пример бардака в сертификатах приведу компанию StartCom, которая в сентябре 2009 получила право выдавать EV (Extended Validation) сертификаты и вот их корневой сертификат: http://www.startssl.com/sfsca.crt

Мало того, что у них в корневом сертификате есть расширение CDP, но и с ссылками на CRL у них в цепочке тоже бардак мутный. Есть подозрение, что это сделано для поддержки какой-то ветки линукса (для совместимости или просто как костыль), но вот такой он опенсорс. Так что не каждый публичный и коммерческий CA следует всем бест-практисам. А вам советую им следовать, тогда меньше вероятность, что вы потом будете гореть в аду.

Изменения в существующих инфраструктурах

Изменение путей в уже существующих инфраструктурах вопрос достаточно серьёзный, хоть и прост в реализации. Если вы решились на такой шаг, то следует руководствоваться следующими правилами:

• пути публикации физических файлов можно располагать в произвольном порядке;
• новые ссылки к файлам, по которым клиенты будут их скачивать должны располагаться первыми, т.е. с более высоким приоритетом (кроме случаев, когда вы добавляете ссылки только для обеспечения более высокой доступности файлов. Тогда новые ссылки можно просто добавить в хвост уже существующим);
• если вы собираетесь уйти от существующих ссылок на CRL/CRT, то в для них следует отключить опцию публикации ссылок в сертификатах. Однако, до окончания действия сертификата CA вы будете обязаны их поддерживать в рабочем состоянии, т.к. они содержатся в уже выданных сертификатах. А новые ссылки появятся только в сертификатах, которые были выпущены после изменения CDP/AIA.
• если у вас корневой сертификат уже содержит расширения CDP/AIA, то вы не можете их оттуда убрать до момента обновления корневого сертификата. При обновлении корневого сертификата на Windows Server 2003, вам потребуется создать CAPolicy.inf файл, прописать нужные настройки (например, как уже указано выше с пустыми CDP и AIA). Более подробно про файл CAPolicy.inf можно прочитать по ссылке: http://technet.microsoft.com/en-us/library/cc728279(WS.10).aspx

Новые технологии

С выходом Windows Server 2008 Enterprise Edition вы можете внедрить в своей сети Online Responder для снижения нагрузки на серверы публикации CRL (хоть пути к OCSP публикуются в расширении AIA, к файлам CRT это никакого отношения не имеет). Но даже внедрение OCSP не решает этих проблем, поскольку реализация OCSP в Windows Server основана на регулярном чтении CRL и, следовательно, зависит от латентности репликации AD и/или DFS, а так же этим сервисом могут пользоваться только клиенты начиная с Windows Vista. Хочу отметить один приятный момент. Если изменения ссылок на CRL/CRT скажутся только на новых сертификатах (уже выпущенные сертификаты ничего не будут знать о новых путях в CDP/AIA), то интегрировать OCSP внутри домена/леса с уже существующей инфраструктурой PKI достаточно легко. Все уже выданные сертификаты могут быть проверены на отзыв с использованием OCSP: Managing OCSP Settings with Group Policy.

Заключение

В данном посте я обозначил ключевые моменты в структуированном (как мне кажется) виде, которые следует знать при планировании публикации файлов CRL/CRT и ссылок на них. Как вы видите, внедрение новых технологий пока что не освобождает от знания и соблюдения рекомендаций публикации CRL/CRT в вашей инфраструктуре PKI. Я считаю этот материал достаточным для начального и среднего уровня знаний по теме revocation и chain building и для более детального изучения всего этого процесса уже следует обратиться сюда: Certificate Revocation Checking in Windows Vista and Windows Server 2008.