Достаточно часто администраторы занимаются выпуском сертификатов с использованием нескольких имён. Например, когда нужно привязать один сертификат к нескольким именам: mail.company.com и owa.compny.com. Однако поле Subject может содержать только одно имя. Для разрешения этой проблемы используется расширение Subject Alternative Name (SAN). В этом расширении вы можете использовать сколько угодно дополнительных имён для сертификата.

Но как правильно же оформить несколько имён в сертификате на примере mail.company.com и owa.company.com? Здесь варианта всего 2:

• Использовать поле Subject и расширение SAN

Данный способ используется чаще для внешних сертификатов. Поле Subject заполняется следующим образом (красным выделены обязательные компоненты):

CN = mail.company.com
OU = <название подразделения>
OU = <ещё какое-то название подразделения>
O = <название организации>
L = <местоположение компании>
C = <код страны, где расположена компания>

Т.е. включается основное имя сертификата (по правде говоря, при использовании SAN, понятие основного имени отсутствует, т.к. все имена считаются равноценными. Здесь следует указывать имя, которое будет использоваться чаще всего приложениями, неподдерживающими расширение SAN) и опционально можно задать дополнительные DN суффиксы, отражающие принадлежность сертификата. И расширение SAN заполняется следующим образом:

DNS Name=mail.company.com
DNS Name=owa.company.com

Как видите, имя из Subject продублировано в SAN. Дело в том, что если в сертификате есть расширение SAN и приложение умеет его обрабатывать, приложение как правило настраивается только на проверку расширения SAN и в Subject они не заглядывают. Но это не всегда так. Иногда приложение смотрит и в Subject и в SAN. В таком случае имена дублировать не обязательно. Но в целях обеспечения совместимости следует ВСЕГДА дублировать имя из Subject в расширении SAN.

• Использовать только расширение SAN

Этот способ редко применяется во внешних сертификатах, а только внутренних. В этом случае поле Subject не заполняется совсем и оставляется пустым. А расширение SAN будет включать все необходимые имена:

DNS Name=mail.company.com
DNS Name=owa.company.com

Такая форма заполнения поддерживается в Internet PKI и описана в RFC 5280. Согласно этому RFC, если поле Subject не определено (пусто), имя для сертификата выбирается из расширения SAN, а само расширение помечается как критичное (см. RFC 5280 §4.2.1.6). Вот примерные пруфпики, как это выглядит в жизни:

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

Здесь продемонстрировано пустое поле Subject.

И перечисление необходимых имён в расширении SAN. Критичность расширения определяется по наличию жёлтого треугольничка и восклицательного знака.

На заметку: что такое критичное расширение (critical extension)? Это просто расширение, которое приложение должно проверить в обязательном порядке. Если приложение видит такое расширение, приложение должно уметь его обработать и понять значение в этом расширении. Если приложение не знает, что делать с этим расширением или приложение не может разобрать значение этого расширения, приложение обязано отклонить данный сертификат. Более подробно о порядке поведения приложения.

Примечание: хоть и заявляется, что приложение должно отклонить сертификат, если значение расширения непонятно, это не в полной мере относится к расширению SAN. Приложение не обязано поддерживать все формы SAN, а может поддерживать только некоторые формы, например, только DNS Name. Но если поддерживаемая форма не может быть распознана, сертификат должен быть отклонён.

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

Какой способ из двух выбрать? А какой считаете более приемлемым. Если это сертификат внешнего веб-сервера, целесообразно использовать первый вариант, поскольку при помощи DN суффиксов можно конкретизировать принадлежность сертификата к вашей компании. А так же если предполагается доступ из приложений неподдерживающих расширение SAN. Это не обязательно компьютерные приложения, это могут быть приложения мобильных устройств. В целях избежания чрезмерного пиара VeriSign'a в моём бложике, представляю образцово-показательный сертификат выполненный первым способом на сайте Thawte: https://www.thawte.com/

Для использования внутри организации можно использовать и второй вариант, с пустым Subject. Например, для логонных сертификатов смарт-карт. Контроллеры домена вообще не смотрят на Subject логонного сертификата, а смотрят только в SAN на предмет наличия UPN в расширении.

Что бы почитать?

• RFC 5280
• Web server certificate enrollment with SAN extension

В различных интернетах всё ещё задают (и не мало) вопросы про проблемы подключения через remote desktop к серверу терминалов защищённому SSL сертификатом. При подключении пользователи видят вот такое:

И сообщение: A revocation check could not be performed for the certificate. Или в русском варианте — не удалось проверить не был ли отозван этот сертификат. А если нажать на View certificate… выясняется, что всё в порядке, сертификат доверен и цепочка построена правильно. Что это такое и как с этим жить?

Причины здесь может быть 2:

• Корневой сертификат цепочки сертификатов не установлен в Trusted Root CAs в *компьютерном* хранилище сертификатов;

Эта проблема встречается примерно в 60-70% случаев появления этой ошибки. Многие привыкли устанавливать корневые сертификаты по двойному клику в пользовательское хранилище. Но, новый mstsc.exe проверяет цепочку сертификатов так, чтобы она заканчивалась на доверенном корневом сертификате установленном в компьютерном хранилище. Поскольку сертификат недоверенный, certificate chaining engine даже и не пытается проверить что-то на отзыв. Как установить сертификат туда:

1. Войдите в систему с правами локального администратора.
2. На рабочем столе нажмите Start и Run… (в случае с Windows Vista/7 можете выделить поле Search programs and files) и в окне наберите MMC. Если появится окно UAC, подтвердите выполнение операции или введите пароль администратора.
3. В открывшейся консоли нажмите File и Add/Remove Snap-in.
4. В списке выделите Certificates и нажмите Add. В появившемся диалоговом окне переставьте переключатель в Computer account и нажмите Next.
5. В следующем окне нажмите Finish.
6. В расскрывшейся оснастке Certificates выделите папку Trusted Root CAs, нажмите правой кнопкой и выберите All Tasks –> Import. Следуйте инструкциям мастера для добавления корневого сертификата в компьютерное хранилище.

• Какие-то CRL'ы в цепочке недоступны.

Когда сертификат выдаётся внутренним CA, но пользователи подключаются к серверу через интернет (например из дома подключаются к RemoteApp по https), очень часто файлы сертификатов и CRL'ы издающего CA недоступны из интернета. В данном случае необходимо связаться с системным администратором, чтобы он переконфигурировал расширения CDP так, чтобы CRL'ы были доступны и из интернета.

Что бы почитать?

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

Недавно в интернете читал интересное обсуждение, в котором утверждалось, что самоподписанные сертификаты подвержены атаке Man-in-The-Middle (MiTM). Давайте разберёмся, что это такое. Есть 2 узла (А и Б). Узел А инициирует соединение с узлом Б отправляя запрос для предъявления сертификата (SSL). Узел Б посылает свой сертификат узлу А. И тут между узлами А и Б появляется узел В (злоумышленник), который перехватывает сертификат и вместо него отправляет свой поддельный сертификат. Узел А думает, что это сертификат узла Б и начинает шифровать этим сертификатом данные, передавая узлу Б. Но на самом деле узел А шифрует данные поддельным сертификатом узла В и злоумышленник читает все шифрованные (а это могут быть и конфиденциальные данные) данные.

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

• Симметричное шифрование

Самый простой, но и небезопасный метод:

1. John Smith хочет безопасно отправить конфиденциальные данные Mary Jane.
2. John генерирует симметричный ключ и шифрует им документ. Документ теперь зашифрован и может быть передан через интернет.
3. Mary Jane получает зашифрованный документ.
4. Mary Jane применяет *тот же самый* симметричный ключ и получает текст в незашифрованной форме.

Минус такого сценария заключается в том, что используется один и тот же ключ как для шифрования и дешифрования. Следовательно, чтобы Mary Jane смогла расшифровать данные ей нужно иметь тот же самый ключ. Этот ключ не должен передаваться вместе с документом, а какими-нибудь другими методами (например, по телефону). Чем больше получателей этого документа, тем выше вероятность, что ключ станет известен ещё кому-то и не существует механизмов, которые бы позволяли определять статус ключа (скомпрометирован или нет). Плюс такого сценария — высокая скорость. Симметричное шифрование выполняется достаточно быстро и не потребляет большого количества процессорных ресурсов. Идеально подходит для шифрования больших объёмов данных.

• Асимметричное шифрование

Метод более сложный, но и более безопасный:

1. John Smith хочет отправить конфиденциальные данные Mary Jane.
2. John использует открытую часть сертификата (с открытым ключом) Mary Jane и этим открытым ключом шифрует данные.
3. Mary Jane получает зашифрованный документ.
4. Mary Jane применяет *закрытый ключ* от своего сертификата и расшифровывает данные.

В нашем сценарии Mary Jane — это веб-сервер, которому нужно передать конфиденциальные данные. А John Smith — клиент, который хочет эти данные передать на сервер. Чисто технически злоумышленник может перехватить открытую часть сертификата Mary Jane и вместо него подложить свой поддельный сертификат с таким же именем. Без дополнительных мер безопасности, John не смог бы отличить настоящий сертификат от поддельного. И здесь появляется важный момент. Перед шифрованием данных John Smith должен проверить этот сертификат на доверие и отзыв. Сертификаты содержат различные средства определения статуса закрытого ключа через списки отзыва. Если сертификат помещён в список отзыва, ему доверять нельзя и использовать его крайне опасно. В случае с самоподписанными сертификатами определить отзыв не представляется возможным. Но можно (как минимум) убедиться, что сертификат выпущен доверенным лицом (или центром сертификации). Для этого John Smith пропускает сертификат через Certificate Chaining Engine (CCE). Если издатель сертификата (или сам сертификат) хранится у John'а в Trusted Root CAs, можно с уверенностью сказать, что сертификат не был подделан злоумышленником и выдан доверенным лицом. Если же сертификата там нет, невозможно убедиться, что это действительно сертификат самой Mary Jane. В таком случае приложение выдаёт ошибку или предупреждение, что не удалось проверить сертификат. Когда пользователь получил такое предупреждение, он должен незамедлительно отменить операцию шифрования (если это ещё не сделало само приложение).

Поскольку закрытый ключ от сертификата хранится только у Mary Jane и он никогда не раскрывается никому, злоумышленнику бесполезно использовать перехваченные пакеты, поскольку закрытый ключ (который нужен для расшифровки данных) никогда не покидает Mary Jane. Хотя тут есть 2 момента. Поскольку самоподписанные сертификаты не имеют централизованного издателя, при большом количестве таких сертификатов появляется вопрос доверия к таким сертификатам:

1. Самое простое — игнорировать ворненги ошибок сертификатов. В таком случае можно надурить отправителя и подсунуть поддельный и недоверенный сертификат. Если вы игнорируете ворненги — вы ССЗБ. Против этого метода защиты не существует.
2. Чуть сложнее — все сертификаты участников обмена шифрованными данными устанавливать в Trusted Root CAs. Тогда ворненгов и не будет. Но при большом количестве таких сертификатов можно ошибочно установить поддельный сертификат к себе в хранилище. И тогда вы будете доверять сертификату злоумышленника.

Следовательно, чисто технически очень сложно организовать атаку MiTM даже с самоподписанными сертификатами. Единственное на что можно рассчитывать — на человеческий фактор. А против человеческого фактора защиты нет никакой. Разве что его можно попытаться снизить за счёт использования централизованного доверенного издателя (центр сертификации). В таком случае придётся установить только один корневой сертификат в Trusted Root CAs. И если сертификат у какого-то участника обмена ВНЕЗАПНО стал недоверенным, можно с определённой уверенностью сказать, что это поддельный сертификат. Но, как я уже отмечал, оба вышеупомянутых пункта относятся как к самоподписанным сертификатам, так и к сертификатам выпущенных централизованным издателем.

Примечание: данный пост содержит сведения об изменении настроек Active Directory и Certification Authority и автор ещё раз обращает ваше внимание на дисклаймер данного блога.

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

• параллельно устанавливают ещё один CA и удаляют старый. При этом сертификаты предыдущего CA не поддерживаются и просто выводятся из обращения (как правило с ними ничего не происходит, а только перестают работать, поскольку CA больше не публикует CRL'ы и проверки таких сертификатов проваливаются). Такой метод применяют, когда количество сертификатов выданных прежним CA невелико и им можно пренебречь и переиздать сертификаты.
• параллельно устанавливается ещё один CA, делают кросс-сертификацию старого CA и удаляют его. При этом сертификаты предыдущего CA поддерживаются и используются в работе. В виду отсутствия предыдущего CA, необходимо дополнительно обеспечить успешную валидацию всех ранее выданных сертификатов.

Если первый метод достаточно прост и тривиален, второй уже требует дополнительных действий со стороны администратора. Это публикация CRL при фактическом отсутствии упразднённого CA и поддержание CRT файлов для построения цепочек сертификатов. И в данном случае старая PKI будет частью новой PKI за счёт кросс-сертификации. Для начала нужно рассмотреть что такое кросс-сертификация. Кросс-сертификация — процесс заверения одной иерархией PKI другой иерархии PKI. При этом заверенная PKI будет являться частью завереямой PKI. Рассмотрим простой пример:

Имеется иерархия CA из корневого Contoso-CA1 и подчинённого Contoso-CA2. Вы создаёте новую иерархию, состоящую из Adatum-CA1 и Adatum-CA2. При этом вы можете сделать кросс-сертификацию между Adatum-CA2 и Contoso-CA1 или Contoso-CA2:

В первом случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Adatum-CA2
                Contoso-CA1
                        Contoso-CA2
                                EndCert

Как видите, клиент не должен явно доверять Contoso-CA1, а только Adatum-CA1. За счёт кросс-сертификации цепочка будет начинаться в иерархии Contoso и заканчиваться в иерархии Adatum.

Во втором случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Adatum-CA2
                Contoso-CA2
                        EndCert

В принципе, можно сделать ещё и вот так:

В первом случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Contoso-CA1
                Contoso-CA2
                        EndCert

Во втором случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
       Contoso-CA2
               EndCert

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

В нашем случае мы создаём новую иерархию Adatum и постепенно избавляемся от Contoso. Важно учитывать, что демонтаж старых центров сертификации можно проводить только после полной настройки новой иерархии PKI.

Подготовка шаблонов сертификатов

1. Войдите в систему с правами Enterprise Admins.
2. Нажмите Start, Run… и введите 'MMC'. Если появится диалоговое окно UAC, подтвердите запуск консоли.
3. В меню File нажмите Add/Remove Snap-ins.
4. В списке выберите Certificate Templates, нажмите Add и нажмите Ok для завершения операции.
5. В открывшейся оснастке найдите стандартный шаблон User. Нажмите правой кнопкой на нём и выберите Duplicate Template. Если появится запрос о выборе версии шаблона укажите Windows Server 2003 Enterprise и нажмите Ok.
6. Во вкладке Properties of New Tamplate укажите новое название шаблона. Например, Cross-signing.
7. Снимите галочку с Publish certificate in Active Directory.
8. Во вкладке Request Handling можете указать другой CSP, если, например, хотите хранить сертификат на смарт-карте (рекомендуется).
9. В Issuance Requirements можете указать требование явного одобрения запроса со стороны администратора CA.
10. Во вкладке Extensions выделите Application Policies и нажмите Edit.
11. Удалите всё из списка, после чего нажмите Add и выберите Qualified Subordination. Нажмите Ok.
12. Во вкладке Security удалите всех из разрешений, кроме глобальной или универсальной группы, которой будет разрешено энролить сертификаты для подписи запросов кросс-сертификации.
13. Нажмите Ok для сохранения изменений и записи шаблона в Active Directory.

Теперь нужно добавить нужные шаблоны в выдачу на CA. Для этого:

1. Войдите на сервер CA с именем Adatum-CA2 с правами Enterprise Admins.
2. Нажмите Start, Administrative Tools и нажмите Certification Authority.
3. Выделите секцию Certificate Templates и в контекстном меню выберите New –> Certificate Template to issue.
4. В списке выделите только что созданный Cross-signing и Cross Certification Authority и нажмите Add.

Теперь запросите сертификат на основе шаблона Cross-signing. Этот сертификат вам потребуется для подписывания запросов сертификатов на основе шаблона Cross Certification Authority.

Создание кросс-сертификата

Кросс-сертификация — это весьма обширная тема. Для нашего сценария нет необходимости рассматривать подробности т.н. qualified subordination, поэтому ограничимся самым простым вариантов без дополнительных ограничений. Для этого создайте текстовый файл с именем Policy.inf и следующим содержанием:

[Version]
Signature = $WindowsNT$

[RequestAttributes]
CertificateTemplate = CrossCA

далее скопируйте сертификат CA Contoso-CA2 на локальный диск. Запустите командную строку и выполните следующую команду:

certreq –policy

В открывшемся диалоговом окне укажите файл сертификата Contoso-CA2 и нажмите Open. Во втором диалоговом окне укажите созданный файл policy.inf и нажмите Open. После чего появится окно выбора сертификата подписи. После указания сертификата подписи нажмите Ok и укажите путь размещения и имя запроса сертификата. После чего выполните следующую команду:

certreq –submit path\cross.req

где path\cross.req — путь размещения и имя файла запроса для кросс-сертификата. Если появилось диалоговое окно выбора сервера CA, выберите тот, в выдаче которого находится шаблон Cross Certification Authority и нажмите Ok.

1. Войдите на сервер CA с именем Adatum-CA2 с правами Enterprise Admins и администратора CA.
2. Нажмите Start, Administrative Tools и нажмите Certification Authority.
3. Выделите секцию Pending Requests, найдите в списке самый последний запрос и в контекстном меню выберите Issue. Предварительно вы можете убедиться, что запрос получился корректный и все данные в нём правильные.
4. Перейдите в секцию Issued Certificates, найдите самый последний сертификат (должен быть наш кросс-сертификат) и экспортируйте его в CER файл.

если открыть сертификат и посмотреть вкладку Certification path, можно увидеть, что цепочка этого сертификата заканчивается не на Contoso-CA1, а на Adatum-CA1. Следовательно, для данного сертификата доверие, да и наличие самого Contoso-CA1 уже не обязательно.

На данном этапе остался последний шаг — публикация кросс-сертификата в Active Directory. Для этого запустите командную строку с повышенными привилегиями (выбрав Run as administrator в контекстном меню значка Command Prompt) и выполните в ней следующую команду:

certutil –dspublish –f path\cross.cer

где path\cross.cer — путь размещения и имя файла кросс-сертификата.

Подготовка к демонтажу старых центров сертификации

Прежде чем демонтировать ненужные центры сертификации, необходимо переподписать все их CRL и поместить их в точки публикации CDP, например, LDAP и/или веб-сервер. Для этого вы должны зайти на каждый демонтируемый сервер CA и выполнить следующую команду:

cd c:\windows\system32\certsrv\certenroll\
certutil –sign .crl 1.crl now+1825:00
certutil –sign +.crl 1+.crl now+1825:00

Certutil –sign переподпишет старые CRL'ы с новым более долгим сроком, в нашем случае — на 5 лет. Т.е. эти CRL'ы будут действительны последующие 5 лет. Далее, вы должны скопировать эти CRL'ы в точки публикации. При этом следует удалить единички (которые были добавлены только для создания нового файла) из имён файлов, чтобы они совпадали с именами файлов в расширениях сертификатов.

Демонтаж старых центров сертификации

Демонтаж старых центров сертификации следует проводить в соответствии с этим руководством: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000

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

Листая тематические форумы, рефералов бложика и переписку в почте, уже набралось немного вопросов, на которые нет смысла делать отдельный пост, но есть смысл вынести в очередной FAQ.

Q: Как узнать тип установленного на сервере Certification Authority?

A: тип Certification Authority можно узнать несколькими методами, которые обычно основываются на реестре:

HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Sanitized Name>

и запись типа REG_DWORD — CAType. И вот что означает каждое значение:

0 — Enterprise Root CA
1 — Enterprise Subordinate CA
3 — Standalone Root CA
4 — Standalone Subordinate CA
5 — Unknown

По большому счёту, если вы задаёте этот вопрос, значит, для вас этот тип — Unknown (5)

Q: Может ли в домене/лесу Active Directory существовать 2 и более иерархий PKI с разными корневыми центрами сертификации?

A: да, вы можете в существующем домене/лесу развернуть несколько независимых иерархий PKI. Сервер CA не использует домен для захвата власти, а только лишь для обеспечения удобства распространения и выдачи сертификатов конечным потребителям.

Q: Можно ли мигрировать сервер CA с платформы x86 на x64? Судя по этой статье: http://support.microsoft.com/kb/298138, это невозможно. Как быть?

A: Сведения представленные в указанной статье не совсем достоверны. Технически бэкап БД выполненный на платформе x86 может быть успешно восстановлен на платформе x64 и каких-то проблем с этим возникнуть не должно. Поэтому вы можете смело планировать миграцию ваших серверов CA с x86 на x64, особенно если существующий CA работает на системе под управлением Windows 2000. В качестве руководства по миграции вы можете руководствоваться следующим вайтпепером: http://technet.microsoft.com/en-us/library/ee126170(WS.10).aspx

Q: Я зашифровал папку с файлами при помощи EFS, но пользователи всё равно могут просматривать содержимое папки? Что это, баг или данные просто не шифруются?

A: Это не баг, а нормальное поведение системы (при условии, что другие пользователи имеют права на просмотр содержимого каталога). Если посмотреть на файловую сисему изнутри, становится понятно, что папка — всего лишь логический контейнер и он хранится в MFT. Папка сама по себе не содержит в себе данных и не имеет размера. А сами данные, которые нужно шифровать находятся в другой части файловой системы. Поэтому если вы зашифровали папку средствами EFS, шифруются сами данные, но обзор списка файлов в шифрованной папке по прежнему разрешён.

Q: мне нужно издать сертификат с некоторыми данными в расширении Subject Alternative Name (SAN). Я создаю запрос с этим расширением, но CA игнорирует это расширение. Как быть?

A: по умолчанию Windows CA игнорирует это расширение в целях безопасности. Для включения этого расширения воспользуйтесь сведениями из этой статьи: http://support.microsoft.com/kb/931351

Q: для чего служат различные контейнеры в AD внутри контейнера Public Key Services?

A: эти контейнеры служат для обеспечения автоматизации работы центра сертификации, подачи запросов и проверки сертификатов.

• NTAuthCertificates — служит для хранения сертификатов центров сертификации, которым разрешено издавать логонные сертификаты (для смарт-карт, для аутентификации по сертификатам в VPN или IIS) для текущего леса. Например, вы используете сторонний центр сертификации, выдающий сертификаты для смарт-карт. Для того, чтобы контроллеры домена распознавали и доверяли этим сертификатам, сертификат стороннего CA должен быть добавлен в NTAuthCertificates. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
• AIA — служит для хранения сертификатов центров сертификации. Сертификаты из этого контейнера используются для ускорения построения цепочек сертификатов при проверке. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
• CDP — служит для хранения списков отзыва (Certificate Revocation List или CRL). Списки отзыва используются для определения статуса конкретного сертификата (отозван или не отозван). CRL'ы из этого контейнера не копируются клиентами. Поэтому CRL опубликованный в данном контейнере может быть использован только если расширение CDP какого-то сертификата явно ссылается на него.
• Certifiation Authorities — служит для хранения собственных или сторонних доверенных корневых центров сертификации. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Trusted Root CAs.
• KRA — служит для хранения выпущенных сертификатов агентов восстановления. Каждый выпущенный сертификат агент восстановления публикуется в этот контейнер в запись соответствующего CA. Важно понимать, что при назначении нового агента восстановления на сервере CA, содержимое данного контейнера не изменяется.
• Enrollment Services — служит для хранения записей и сертификатов всех Enterprise CA в текущем лесу. Клиенты используют этот контейнер для обнаружения Enterprise CA.
• OID — содержит все OID'ы зарегистрированные в вашей компании. В том числе  Issuance, Application Policies, Certificate Templates OID's.
• Certificate Templates — служит для хранения сведений о всех шаблонах сертификатов текущего леса.

Q: я создал шаблон версии 3 (Windows Server 2008 Enterprise Edition) для смарт-карт, но при энроллменте я получаю ошибку. В чём дело?

A: исторически CSP (Cryptography Service Provider) смарт-карт не поддерживают алгоритмы CNG (Cryptography New Generation), которые реализованы в шаблонах версии 3. Следовательно, вы не можете использовать шаблоны версии 3 для смарт-карт. Вместо этого вы должны использовать шаблоны версии 2 (Windows Server 2003 Enterprise Edition).

Q: я установил MS OCSP Responder, но папка веб-приложения пуста. Что должно быть в папке OCSP?

A: Имплементация OCSP в Windows основывается на ISAPI фиьтрах, реализованных в библиотеке ocspisapi.dll. Поэтому при создании веб-приложения OCSP путь к нему указывается как %systemroot%\SystemData\ocsp. В этой папке есть только папка aspnet_client, но файлов никаких нет. Их быть и не должно.