Disclaimer: Эта статья содержит сведения о правке реестра. Перед внесением изменений в системный реестр рекомендуется изучить процедуру его восстановления. Для получения дополнительных сведений о восстановлении реестра см. разделы «Восстановление реестра» или «Восстановление раздела реестра» справочной системы редактора реестра.

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

• Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов — подведение итогов (ссылку будет по окончании написания этого цикла).

В предыдущей части мы поговорили о процессе аутентификации по сертификату (или смарт-картой), но не поговорили о том, как сертификат связывается (ассоциируется) с учётной записью пользователя в Active Directory. Процесс ассоциации сертификата с учётной записью называется certificate mapping. В мире Active Directory существует 2 вида маппинга:

• Implicit certificate mapping;
• Explicit certificate mapping.

Implicit certificate mapping

Implicit certificate mapping (в переводе звучит как «неявный» маппинг. В точности перевода могу ошибаться) является самым простым, шустрым и очевидным методом ассоциации сертификата с учётной записью пользователя. Для этого клиентский сертификат должен содержать расширение Subject Alternative Name и в нём должен быть прописан UPN (User Principal Name) пользователя:

Other Name:
     Principal Name=Administrator@contoso.com

Контроллер домена извлекает UPN пользователя из сертификата и пытается найти такой же UPN в глобальном каталоге. UPN хранится в атрибуте sAMAccountName. Если такой UPN найден, сертификат привязывается к учётной записи пользователя с указанным UPN. В противном случае считается, что учётная запись не найдена и аутентификация проваливается.

На заметку: некоторые пользователи (особенно, которым нужен доступ в 2 и более леса, которые не связаны доверительными отношениями) думают, что можно накидать несколько UPN'ов в расширение и получать профит — один универсальный сертификат для логона в 2 и более леса. Если в расширении SAN указано несколько различных UPN'ов, контроллер домена будет читать только первый из списка.

В 99% случаев вы будете использовать только implicit certificate mapping, который используется по умолчанию.

Explicit certificate mapping

В отдельных случаях у вас может и не быть возможности использовать implicit certificate mapping. Например, это сторонний (или коммерческий) CA, который по каким-то причинам не может или не хочет включать UPN пользователя в расширение SAN. Или у вас просто есть сертификат от чужого леса и вы его хотите использовать для двух лесов, которые друг о друге ничего не знают. И знать не хотят, видимо. С implicit certificate mapping вы можете использовать сертификат только в одном лесу или в нескольких лесах — но при условии, что UPN'ы в лесах совпадают.

Так же, существует ненулевая вероятность, что у вас будет сертификат с прописанным UPN в расширении SAN, но вы захотите использовать этот сертификат для другого UPN. Что делать? По умолчанию, контроллер домена при наличии UPN в SAN применяет *implicit mapping*, т.е. привязка по UPN и он даже не попытается попробовать explicit mapping. Хоть, такие случаи достаточно редки, но бывают нужны, вы можете отключить implicit mapping на уровне домена создав следующее значение в реестре (на контроллерах домена):

KEY =  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Type = DWORD
Value Name = UseSubjectAltName
Value Data = 0

Примечание: это возможно только для Windows Server 2008 и выше. Детали описаны в статье How to disable the Subject Alternative Name for UPN mapping. Но я ещё раз предупреждаю, что делать это следует только когда вы чётко понимаете, что вы делаете и какие последствия вас могут ожидать.

One-to-one mapping

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

Суть этого метода заключается в том, что определённые свойства сертификата должны быть описаны в атрибуте altSecurityIdentities (доступно через Attribute Editor) свойств учётной записи пользователя. Вот как можно создать маппинг one-to-one в консоли Active Directory Users and Computers:

1. Откройте оснастку Active Directory Users and Computers (dsa.msc);
2. В меню View установите флажок на Advanced Features;
3. Выберите учётную запись пользователя, с которой будут связываться сертификаты группы работников;
4. В контекстном меню выберите Name Mappings;
5. В открывшемся окне, кнопкой Add добавляете необходимые сертификаты.

Смотрите, здесь уже используется (и не отключается) маппинг по Issuer DN Name и Subject DN Name. Т.е. если контроллеру предъявляют сертификат с такими же значениями полей Subject и Issuer, он привяжет этот сертификат к этой учётной записи, где настроен маппинг. Если снять чек-бокс «Use Subject for alternate security identity», любые сертификаты, выданные конкретным сервером CA будут мапиться к этой учётной записи и это будет many-to-one certificate mapping. Но не следует использовать маппинг только по издателю. О более гибких примерах маппинга мы поговорим ниже. Вот пример:

В данном случае любой сертификат с конкретным Subject DN, который выдан конкретным CA будет мапиться к рассматриваемой учётной записи.

Many-to-one mapping

Этот сценарий применяется очень редко, но для того, чтобы не оставлять пробелов, я решил написать несколько слов об этом в исключительно информативных целях. Суть этого метода заключается в том, что несколько разных сертификатов мапятся к одной учётной записи. Допустим, есть группа временных работников (или партнёры из другой компании), у которых нет индивидуальной учётной записи в Active Diectory, но им нужен доступ к веб-сайту, который использует аутентификацию клиентов по сертификатам. Как говорится, нет ножек — нет и мультиковнет учётной записи — нет доступа.

В случае с explicit certificate mapping, алгоритм поиска учётной записи с которой можно связать предъявленный сертификат усложняется. Контроллер домена будет искать в своей базе сертификаты и пытаться их забиндить по следующим признакам (именно в такой последовательности, как они здесь указаны):

1. Точное совпадение полей Subject и Issuer — X509:<I><S>
2. Только по полю Subject — X509:<S>
3. По полям Issuer и Serial Number — X509:<I><SR>
4. По расширению Subject Key Identifier — X509:<SKI>
5. По Thumbprint (хешу всего сертификата) — X509:<SHA1-PUKEY>
6. И, наконец, по полю RFC822 Name (он же адрес электронной почты) — X509:<RFC822>

Вот примерная таблица (зелёным отмечены правильные условия проверки, красным — неправильные):

Например, у пользователя есть сертификат на CN=Oleg Krylov, OU=Users, DC=contoso, DC=com и который выдан CN=Contoso Corporate CA, DC=contoso, DC=com. Из картинки видно, что мы можем применить следующий биндинг: X509:<I><S>. И вот как его следует использовать в altSecurityIdentities:

• X509:<I>DC=com,DC=contoso,CN=Contoso Corporate CA

Во-первых, элементы DN размещаются в обратном порядке от представления в сертификате. Т.е. сначала RDN, а потом уже CN, потому что они так кодируются в сертификате. Вот, пример ASN1 структуры сертификата VeriSign:

И посмотрите на Subject этого сертификата в UI: http://EVSecure-aia.verisign.com/EVSecure2006.cer. Т.е. вам необходимо взять сертификат и переписывать поле Subject/Issuer снизу вверх. Во-вторых, каждый элемент DN разделяется запятой и вокруг запятых пробелов быть не должно.

У сертификата есть расширение Subject Key Identifier = c1 2f a9 f1 c0 22 d4 37 a2 20 07 1d b9 ab 4a 12 ef f2 f9 fa и вы хотите сделать маппинг по этому расширению. Для этого в свойство altSecurityIdentities необходимо прописать строку следующего содержания:

• X509:<SKI>c12fa9f1c022d437a220071db9ab4a12eff2f9fa

Если делаете маппиг по схеме X509:<I><SR> (по издателю и серийному номеру), следует учитывать, что байты серийного номера должны идти в обратном порядке. Т.е. если в сертификате мы видим вот такой серийный номер: 2e 33 87 4f 6f e2 d4 1e d3 ff ff 35 f6 a4 c9 18, в условии маппинга следует переписывать байты справа налево: 18 c9 a4 f6 35 ff ff d3 1e d4 e2 6f 4f 87 33 2e или вот так:

• X509:<I>DC=com,DC=contoso,CN=Contoso Corporate CA<SR>18c9a4f635ffffd31ed4e26f4f87332e

Это связано с тем, что в структурах C серийный номер (CRYPT_INTEGER_BLOB) записывается в обратном порядке и KDC будет использовать серийный номер так, как он хранится в структуре.

Если на каком-то этапе удалось обнаружить однозначное сходство — дальнейшие попытки биндинга сертификата не производится, а сертификат привязывается к учётной записи и пользователь продолжает процесс аутентификации. Кстати, почему так сложно? Почему бы не взять и не просто сверить 1:1 предъявленный сертификат, с опубликованным в свойствах учётной записи? Ответ тут достаточно очевидный — вы можете использовать many-to-one (когда сравниваются только определённые атрибуты сертификатов). И если вам надо связать множество сертификатов с одной учётной записью, их всех придётся публиковать, а это может неприятно отразиться на репликации. И короткие строки сравнивать быстрее, чем бинарные массивы.

Примечание: many-to-one certificate mapping можно реализовать как средствами Active Directory (описано в статье), так и средствами IIS. При установки роли веб-сервера, у вас есть 2 похожих пункта:

С виду их не отличишь, но теперь вы знаете, что первый пункт (Client Certificate Mapping Authentication) использует маппинг настроенный в Active Directory, а IIS Client Certificate Mapping использует маппинг настроенный в IIS. Подробнее: Many-To-One Mappings <manyToOneMappings>.

Эпилог

Чувствую, что написал очень много и непонятно. Я не обещал, что будет легко. В принципе, вы можете читать только раздел Implicit certificate mapping, а остальное — только когда потребуется или просто ради лулзов . В следующей части перейдём немного от теории к практике.

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

• Windows Vista Smart Card Infrastructure

В первой части серии постов про клиентскую аутентификацию при помощи сертификатов мы сделали вброс и поговорили об основных моментах этой темы. Мы поняли, что сертификаты всяко секурней, чем эти ваши пароли (если их правильно приготовить!). В этой части я предлагаю заняться теорией. Долгой, сложной, нудной, но необходимой. Сегодня теория будет состоять из изучения общего принципа работы аутентификации по сертификатам и как это выглядит в общении клиента и сервера.

Общая схема аутентификации по сертификатам

Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:

1. Пользователь запрашивает доступ к некоторой сетевой службе;
2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

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

1. Клиент запрашивает установку безопасного канала;
2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Логон смарт-картой или PKINIT

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT. PKINIT, в свою очередь, является лишь надстройкой над керберосом (или расширением протокола). Вот как он примерно работает:

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

1. Пользователь вводит PIN от смарт-карты и посылает запрос AS-REQ на контроллер домена (он же Key Distribution Center — KDC). Этот запрос содержит преаутентификационные данные PA_PK_AS_REQ, которые, в свою очередь, содержат логонный сертификат и подписанная временная метка и опциональные атрибуты. В качестве опциональных атрибутов, клиент посылает список поддерживаемых алгоритмов, корневых CA, параметры Diffie-Hellman и т.д. Более детально структуру запроса (а там есть достаточно занятных вещей) можно найти в RFC 4556  §3.2.1 (пункт 5 на странице 12). В связи с этим (например, передача списка доверенных корневых CA от клиента на сервер) время логона смарт-картой будет значительно медленней, чем при связке логин/пароль. Плюс расходы на криптографические операции.
2. Сервер KDC проверяет запрос и пробует ассоциировать полученный сертификат с учётной записью пользователя. Если сопоставление сертификата с учётной записью произошло успешно, KDC формирует ответ AS-REP, включая в него Ticket-Granting Ticket (TGT) и прочую необходимую информацию. Ответ подписывается сертификатом самого KDC (именно поэтому, при использовании смарт-карты для логона, сервер KDC должен иметь свой собственный сертификат (о нём мы поговорим в следующих статьях).
3. Клиент проверяет этот ответ и проверяет подпись (вместе с сертификатом KDC). Если с ответом и сертификатом всё хорошо, клиент, на основе имеющегося TGT, генерирует Ticket Granting Service запрос — TGS-REQ для доступа к конкретной службе и отправляет его на KDC.
4. KDC проверяет запрос TGS-REQ и в случае положительного вердикта формирует ответ Ticket-Granting Service (TGS-REP), включая в него всю необходимую информацию для интерактивного логона, включая все необходимые SID'ы и учётные данные для аутентификации при помощи NTLM.
5. Клиент генерирует специальный токен GSS-API (RFC 1964) и в него заворачивает полученный TGS-REP. На выходе получается запрос AP-REQ, который направляется уже к конкретной службе, куда нужен доступ.
6. Здесь, собственно, происходит уже обоюдная аутентификация сервера и клиента (уже с использованием Kerberos) и между ними уже начинается свой собственный диалог. Возможно, о бабах

В принципе, вот как примерно (на достаточно высоком уровне) происходит клиентская аутентификация по сертификату. Кое что я опустил (что нам не столь актуально в рамках рассматриваемой статьи), но кое что мы будем более плотно рассматривать в следующих статьях — например, маппинг сертификатов (ассоциация или сопоставление сертификата с учётной записью в Active Directory).

На последок, особо пытливым умам — увлекательное чтиво:

• MS-PKCA
• MS-PAC
• MS-KILE
• RFC 4556
• RFC 1964

Данная серия постов заказана и оплачена благотворительным фондом винниклОлега Крылова и всех-всех-всех.

Исходя из названия серии, мы, очевидно, будем говорить про цифровые сертификаты и аутентификацию. Для начала предлагаю классический бэкграунд аутентификации другими средствами (паролями же!).

Password-based authentication background

Почти всю свою историю человек использует аутентификацию на основе комбинации логин и пароль. Логин уникально идентфицирует пользователя, а пароль (или секретное слово) подтверждает, что я — это я, а не Вася, который выдаёт себя за меня. Но давайте посмотрим слабые места парольной аутентификации в IT:

• Пароли очень короткие (5-8 символов);

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

• Пароли забываются;

Действительно пароль вида $gf)a90sfLq*wrF4 запомнить нелегко. С очень высокой долей вероятности, что пользователь после удачных выходных вряд ли в понедельник утром вспомнит его — звонок в тех.поддержку. Пока решается его вопрос с паролем, пользователь простаивает и ничего не делает, просто любуется экраном логона. Но можно выйти из ситуации и обойтись без звонка в тех.поддержку:

• Пароли записываются на бумажки и приклеиваются на монитор;

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

• Один и тот же пароль используется для множества сетевых ресурсов одновременно;

Нередко, когда пользователь зарегистрирован в десятке (а то и в десятках) мест, где используется один и тот же пароль. Потерял 1 пароль — потерял доступ всюду. Лично я не в состоянии удержать в голове все пароли от всех (да хотя бы топ-10) сайтов, где я бываю. Признаюсь, что у меня есть секретный текстовый файл, где я записываю все свои пароли и на сегодняшний день он имеет размер в 5кб. Я знаю, что это несекурно, но пока ничего лучше не придумал (если есть идеи, можете их озвучить в комментариях).

Об этом можно говорить долго и упорно, но смысла это не добавит, поэтому переходим дальше.

Introduction to certificate-based authentication

Цифровые сертификаты — это альтернативная форма идентификации пользователя. Здесь и далее я буду говорить про цифровые сертификаты в контексте Active Directory.

Цифровой сертификат — это документ, защищённый цифровой подписью (т.е. защищён от подделки), который содержит необходимую информацию о его владельце, которая позволяет уникально идентифицировать пользователя. Эта информация включает как минимум логонную информацию (адрес учётной записи в каталоге Active Directory или его User Principal Name — UPN). Поскольку цифровые сертификаты это часть инфраструктуры открытого ключа, они обязательно содержат открытый ключ.

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

• Зная открытый ключ, невозможно вычислить закрытый ключ и наоборот.
• Данные зашифрованные одним ключом (например, открытым) могут быть расшифрованны только вторым ассоциированным (например. закрытым) ключом.
• Если мы шифруем данные открытым ключом — это шифрование и данные прочитать может только владелец закрытого ключа.
• Если мы шифруем данные закрытым ключом — это цифровая подпись и данные прочитать может любой пользователь, но создать конкретную цифровую подпись может только владелец закрытого ключа.

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

Смарт-карта это устройство со встроенным микрочипом, который хранит цифровой сертификат и закрытый ключ от него. Микрочип устроен так, что извлечь закрытый ключ из него не представляется возможным, а получить доступ можно только путём ввода отдельного пароля, называемым PIN (Personal Identification Number). Ряд смарт-карт оборудуются дополнительным элементом физической защиты, при разрушении которой уничтожаются и хранимые на них ключи и сертификаты. Это защитная мера, которая предотвращает доступ к ключам и защищённой этими ключами информации при попытке физического доступа к микрочипу, что и есть главное условие безопасности.

Где можно применять аутентификацию пользователей по сертификатам?

В Microsoft Windows мы можем применять пользовательские сертификаты для:

• Интерактивного логона в домен (требуется смарт-карта);
• Логона на сервер терминалов при помощи Remote Desktop (требуется смарт-карта);
• Аутентификации на веб-странице;
• Аутентификации в VPN;
• Аутентификации в 802.11х сетях (они же wireless).
• Аутентификации в ActiveSync;
• и ещё по мелочам.

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

В разных интернетах ходят разные толки по поводу Policy CA. В своё время я давал краткую справку о нём: Обсуждение схем иерархии Certification Authority и есть необходимость немного дополнить ту статью и показать применением выделенного Policy CA в реальном мире. Назначение Policy CA вполне понятно — разделять PKI на одну или несколько веток, которые будут различаться правилами выдачи и обслуживания сертификатов. Интернеты (и разные там специалисты) всячески рекомендуют деплоить 3-х уровневые иерархии вида:

Offline Root CA
           Offline Policy CA
                      Online Issuing CA

Это считается бест-практисом. Отдельные люди указывали мне, что совмещение ролей (Policy и Issuing) не есть хорошо по причине безопасности и всё такое. Но если говорить о бест-практисах, то их здесь нету совсем. Есть только некоторые рекомендации, по которым можно подобрать себе оптимальную иерархию. Всё остальное является следствием буйной фантазии. Давайте ещё раз пробежимся по этим моментам.

Когда применяем 1-уровневую иерархию?

Если у вас небольшая компания (скажем, человек 10-100) без особых требований к PKI, вы спокойно разворачиваете одноуровневую иерархию с Online Root CA и используете сертификаты для логона (VPN, IIS и/или применяете смарт-карты) или шифруете данные. Как пример. Хоть я в предыдущей статье весьма критически относился к такому решению, оно в реальном мире вполне себе жизнеспособно (опыт иногда меняет отношение к каким-то вопросам в ту или иную сторону). Не потому что она ВНЕЗАПНО стала безопасной, а потому что это элементарно выгодней, чем покупать отдельное железо и лицензию Windows Server, даже если посчитать все риски. Плюс, экономия на административных издержках. Т.е. это случаи, когда компрометация PKI не ведёт к краху всего бизнеса, хотя это не очень приятно.

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

Когда применяем 2-уровневую иерархию?

Если вы интегрируете PKI в свою сеть более тесно (вы внедряете цифровые подписи, устанавливаете VPN между сайтами, появляются удалённые SCCM/OpsMgr клиенты и т.д.), вы скорее всего будете более благоразумны и примените 2-х или 3-х уровневую иерархию. На этом этапе у вас PKI может начать делиться, потому что сферы применения PKI становятся шире. И вот здесь может появиться желание вбахать выделенный Policy CA, который опишет политику применения (CPS) сертификатов в вашей организации. С одной стороны это выглядит идеологически правильно. Но с другой стороны это не очень практично. Дело в том, что CPS можно прикрутить и к издающим CA, совместив роль Policy и Issuing CA. Об этом я уже писал в предыдущей статье.

Даже если у вас на уровне шаблонов сертификатов действуют разные политики, их вполне возможно описать в пределах одного CPS. Политики на уровне шаблонов могут быть очень разнообразные: например, чтобы получить сертификат для шифрования данных достаточно залогониться в систему. А чтобы получить логонный сертификат на смарт-карте, нужно оформить соответствующую заявку и нотариально заверить у руководителя отделом. Для получения сертификата цифровой подписи (для подписи документов), нужно в должности быть руководителем какого-то отдела. Это наиболее распространённые примеры из реальной жизни.

Учитывая, что в этих случаях у вас будет один CPS, вы можете на уровне издающего CA применить OID = All Issuance Policies (2.5.29.32.0) в CAPolicy.inf:

[PolicyStatementExtension]
Policies = SomeCPS

[SomeCPS]
URL = Some URL 
OID = 2.5.29.32.0

Т.е. CA может выдавать сертификаты с использованием любых политик выдачи и использования сертификатов, которые более конкретно определены в CPS. Так же, данный сценарий позволяет провести последующую кросс-сертификацию с другой PKI (см. Что в OID'е тебе моём?). Если CA может издавать сертификаты только по конкретным политикам, вы можете ограничить CA только ими, применив следующий шаблон для CAPolicy.inf:

[PolicyStatementExtension]
Policies = CPS1, CPS2, CPS3

[CPS1]
URL = URL1
OID = 1.3.6.1.4.1.12345.1

[CPS2]
URL = URL2
OID = 1.3.6.1.4.1.12345.2

[CPS3]
URL = URL3
OID = 1.3.6.1.4.1.12345.3

В результате, CA сможет выдавать сертификаты на основе тех шаблонов (здесь я имею ввиду применение в Windows PKI), где эти политики определены.

Заметка: всякие верисайны, тафты и прочие коммерческие CA как правило применяют 1-2 уровневые (хотя есть и 3-х уровневые) иерархии. Но у них специфика другая.

Если всё так просто умещается в 2-х уровневой иерархии, когда же нам может понадобиться выделенный Policy CA?

Когда применяем 3-х уровневую иерархию?

Наконец-то добрались до цели нашей экскурсии. В реальной жизни выделенный Policy CA потребуется только когда у вас будут две и более совершенно разных политик выдачи и использования сертификатов. Наиболее классический случай — когда вы ведёте бизнес в разных странах.

Например, в России у вас головной офис, а в Европе у вас находится филиал. В этом случае у вас скорее всего политики выдачи для родной страны и Европы будут очень сильно отличаться, потому что законодательства в этих странах тоже разные. Но и здесь возможны варианты. Если все CA находятся в головном офисе (и европейский офис подключается к головному через VPN), вы можете рассмотреть предыдущий раздел. Это означает, что вы сделаете 2 издающих CA: один для локального офиса, второй для европейского. Естественно, на каждом CA будут описаны различные политики сертификатов.

Если же в европейском филиале находится свой CA и им управляет местный персонал, тогда понадобится выделенный Policy CA. Т.е. вы в головном офисе установите Policy CA, ограничите его на уровне CPS и тогда европейский офис может спокойно управлять своими издающими CA без риска нарушить политики сертификатов. При этом, для головного офиса вы можете использовать 2-х уровневую иерархию. Разумеется, в этом случае для Policy CA вы не сможете использовать All Issuance Policies, а нужно применить свой кастомный OID (или несколько, см предыдущий раздел).

Схожий сценарий: у вас есть большое количество филиалов, в каждом установлен свой издающий CA (но все они подчинаются одному корневому CA), т.к. интернеты между ними не очень шустрые и стабильные. И каждым CA в филиале управляет своя команда администраторов. В этом случае есть смысл (но совершенно не обязательно) под корнем установить Policy CA, на нём определить CPS и уже под ним размещать издающие CA филиалов. В этом случае от администраторов филиалов не требуется лишних телодвижений по прописыванию CPS в CAPolicy.inf, потому что CPS определённые на Policy CA будут наследоваться на сертификаты издающих CA.

Следующий сценарий, более специфический: вы хотите сделать root signing. Root signing — это когда коммерческий CA (VeriSign, Thawte, etc) выдаёт сертификат для вашего CA. В этом случае вы исключаете проблему организации доверия вашим сертификатам, потому что все сертификаты в этом случае будут заканчиваться корневым CA верисайна или какого-нибудь другого well-known коммерческого CA. В этом случае коммерческий CA выдаст сертификат для вашего выделенного Policy CA, который не может быть совмещён с издающим (это одно из требований к root signing).

Ещё один специфический сценарий: в вашей компании несколько лесов Active Directory. Если вы не применяете cross-forest enrollment, вам вероятнее всего придётся сделать выделенный Policy CA, который определит общую политику сертификатов для всех лесов Active Directory. И в каждом лесу уже устанавливаете издающие CA. Если же каждый лес будет иметь свой независимый набор политик сертификатов, можно ограничиться двумя уровнями.

Последний сценарий в этом разделе: вы планируете кросс-сертификацию с другой PKI. При этом под кросс-сертификацию должны подпадать все ваши издающие CA. В этом случае у вас есть выбор — оставаться на 2-х уровнях и получить на каждый CA по кросс-сертификату или сделать выделенный Policy CA и тогда получите только 1 кросс-сертификат. Вы можете сказать, что можно же получить один кросс-сертификат для корневого CA и тогда все издающие CA будут подпадать под кросс-сертификацию. С одной стороны это действительно возможно. Но кросс-сертификация подразумевает наличие CPS (а так же возможны внешние аудиты на предмет следования собственному CPS), который никогда на корневых CA не определяется.

Итоги

Про 4-х уровневую иерархию я ничего рассказывать не буду, потому что не посчастливилось лицезреть такое. Если что, можете прочитать об этом в книге Комара —http://www.sysadmins.lv/pkibookshelf.aspx. А мы, в свою очередь, немного освежили память об иерархиях в PKI и более детально рассмотрели некоторые аспекты, касающиеся Policy CA и разрушили миф о бест-практичности 3-х уровневой иерархии. Т.е. каждая PKI строится с учётом требований бизнеса и управления, а не бизнес и управление строятся под конкретную выбранную иерархию и этот пост лишь раскрывает некоторые аспекты, которыми можно руководствоваться для проектировании PKI.

В любом случае, как сделаете — так и будет хорошо. Лишь бы вы (как проектировщик PKI) подошли к делу с головой и ваше решение заработало, как запланировало.

Недавняя тема «Мифы о мифах» подтолкнула меня к очередному эпосу на тему мифов в целом и PKI в частности. Основная мысль заключается в том, что частный результат может быть очень даже противоположным общему. Хоть фундамент PKI и выглядит монолитным, его основание закладывается из множества составных деталей. И, следуя указанной мысли, одна деталька не всегда соответствует конечному итогу.

Возьмём один абстрактный пример: администратор X нашёл способ обхождения ограничения RFC (RFC5280, §4.2.1.9) путём подписания пользовательским сертификатом (например, сертификатом EFS или secure email) другого сертификата. Здесь нужно дать большое пояснение сути проблемы.

В бытность использования сертификатов версии 1 было отмечено множество проблем. Например, невозможно было определить тип сертификата — конечный сертификат или сертификат промежуточного CA. Так же было невозможно узнать для каких целей может использоваться сертификат (например, только для шифрования файлов). Нельзя было проверить сертификат на отзыв, если CRL издателя не установлен (закеширован) в системе. Так же, проблемы начинались при обновлении сертификатов самих CA. Вобщем, проблем было много и гибко использовать сертификаты не представлялось возможным. Версия 2 решила только одну проблему — обновление сертификата CA. И только сертификаты версии 3 стали способны решить многие проблемы тех времён. Это было достигнуто за счёт появления расширений сертификата. Расширения сертификатов могут содержать всевозможную информацию о самом сертификате, издателе, владельце ключа и т.д. Например, мы можем применить расширение Enhanced Key Usage и на основании его содержимого принимать решение, можно ли использовать предъявленный сертификат для конкретной задачи или нет. Например, в правильном мире ни одно приложение (rfc-conformant) не согласится использовать сертификат с EKU = Encrypting File System для установки цифровой подписи и т.д. Дальнейшая дискуссия пойдёт только о сертификатах версии 3.

Вернёмся же, к нашему вопросу. Согласно RFC5280, §4.2.1.9, подписывать сертификаты можно только сертификатом, которое содержит расширение Basic Constraints и свойство cA (certification authority) выставлено в true. Так же это расширение должно быть помечено как критичное. Если одно из этих условий не выполняется, такой сертификат не может использоваться для подписи других сертификатов (условно говоря, выступать в роли CA). Но пытливые умы находят лазейку (в виде утилит вида openssl, makecert или низкоуровневых API) и подписывают пользовательским сертификатом другой сертификат. Слабонервные могут впасть в панику, хвататься за острые и режущие предметы или выбрасываться из окон верхних этажей небоскрёбов, потому что мир рухнул. Они так верили в PKI, а тут какой-нибудь openssl взял и дискредитировал всю нерушимую идею PKI. Необходимо как-то запретить такие вольности.

Но я спешу успокоить вас. PKI существует очень давно и сегодня подобные фокусы не пройдут. Давайте посмотрим, как это выглядит на картинках. Я взял свой сертификат, предназначенный только для Code и Document Signing и подписал другой сертификат:

посмотрим вкладку Certification path:

А тут конечный сертификат ВНЕЗАПНО is Ok. Правда, можно заметить, что на предыдущем сертификате в цепочке стоит треугольничек. Когда я запустил файл, Windows пропустил сертификат через упрощённый движок построения цепочки (certificate chaining engine или сокращённо CCE). Поскольку CCE очень любит rfc и не любит openssl, он задетектировал ошибку, что предъявленный сертификат не может использоваться для указанного применения. Но мы пока не видим, каким боком тут вырос Basic Constraints. Для этого мы воспользуемся certutil'ом и посмотрим более детальный трейс CCE (публикую только отрывок):

ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
ChainContext.dwErrorStatus = CERT_TRUST_INVALID_BASIC_CONSTRAINTS (0x400)

вот тут мы и видим, что проблема с Basic Constraints. Дело в том, что мой сертификат подписи не содержит этого расширения, следовательно не может использоваться для подписывания других сертификатов. Вот описание этой ошибки по версии MSDN:

The certificate or one of the certificates in the certificate chain has a basic constraints extension, and either the certificate cannot be used to issue other certificates, or the chain path length has been exceeded.

Следовательно, если предъявить подобный сертификат любому приложению, которое использует rfc-conformant certificate chaining engine (будь то встроенный в Windows или что-то своё), приложение должно очень сильно ругнуться на сертификат и отклонить его.

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

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

• http://www.sysadmins.lv/content/pki/self.crt
• http://www.sysadmins.lv/content/pki/vpodans_signing_cert.crt (этот сертификат нужно будет установить в контейнер Intermediate CAs, чтобы можно было корректно построить цепочку сертификатов).