Update 05.12.2009: выпилена часть про смену пароля как не совсем правильную (см.каменты). Судя по логике смены паролей компьютерами в домене, можно реализовать Offline CA в доменной среде с большим сроком бездействия. Но это всё равно не отменяет того факта, что такое решение будет не совсем правильным.

Сегодня хочу немного обсудить несколько (все не получится :-() вопросов планирования ирерархий Certification Authority (CA), как это делается в реальном мире. Как таковых бест-практисов на эту тему не существует, равно как и бест-практисов по планированию лесов Active Directory. Есть только несколько стандартных классических схем и рекомендаций на основании которых можно выбирать. Этот вопрос очень серьёзный, поскольку иерархии PKI и AD очень редко меняются в силу сложности и дороговизны процесса. И с тем вариантом, который вы выбрали на этапе планирования, скорее всего вы будете жить очень долго.

Лирическое отступление

В реальной жизни домены и PKI в основном развёртываются по одному из трёх сценариев:

• Говноадминами в метро на коленке за 15 минут;
• Системными администраторами после тщательного (по мере сил) анализа существующей инфраструктуры;
• Системными интерграторами или аутсорсерами, грохая огромные деньги на полный и компетентный анализ существующей инфраструктуры, учитывая требования бизнеса с запасом на 5 лет минимум.

Не всем посчастливилось устроиться работать в компанию последней группы и чаще всего приходится работать в первых двух. С первым вариантом даже обсуждать нечего, потому что с такими администраторами говорить вовсе не о чем, разве что смаковать последние новости с ЛОРа, секлаба и двача. Я всё-таки надеюсь, что этот пост будет полезен администраторам второй группы.

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

1. Root CA — корневой CA, который является наиболее критической точкой в инфраструктуре, потому что потеряв/скомпрометировав его, ваша PKI и репутация компании летит к чёрту, поскольку это та точка доверия, которая проверяется весьма условно. Т.е. вы доверяете тому или иному корневому сертификату только на основании каких-то косвеных данных или собственных предпочтениях. Технически проверить «хорошесть» корня не представляется возможным. Как правило выдаёт сертификаты только подчинённым Policy CA.
2. Policy CA — даже не знаю как его перевести, поэтому не буду. Но его суть сводится к тому, что данный тип CA определяет политику сертификации на данном CA и на всех последующих CA в цепочке. Каждый Policy CA характеризуется своим собственным CPS (Certificate Practice Statement). Поэтому если у вас на предприятии используются различные схемы проверки подлинности участников, которые запрашивают сертификаты и требования к ним, а так же мероприятия по организации CA, то каждая такая схема выносится в отдельный CPS и отдельный Policy CA. Так же, как и корень, является критической точкой в иерархии, но чуть меньше, чем корневой CA. Поскольку изъять из эксплуатации (decomission) Policy CA всяко проще, чем корневой. Об этой проблеме я уже говорил в посте Certificate chaining engine (CCE) и отзыв корневых сертификатов. Policy CA может быть выделенный и выдавать сертификаты только подчинённым Policy или Issuing CA. А может быть и одновременно совмещён с ролью Issuing CA.
3. Issuing CA — издающий CA, который уже выдаёт сертификаты конечным потребителям — пользователям, компьютерам, различным сетевым устройствам. Каждый Issuing CA должен подчиняться тем требованиям и указаниям, которые описаны в CPS Policy CA.

Enterprise Root CA — хороший выбор?

В условиях малого и среднего бизнеса не всегда можно набрать компетентный в этих вопросах персонал, поэтому админстраторы обычно делают всё попроще — ставят 1 или 2 Enterprise Issuing CA и радуются жизни. В таких ситуациях один единственный CA выполняет все 3 роли — он и корневой, и Policy и издающий CA. Чем это плохо? Учитывая тот факт, что сервер CA находится постоянно в сети и его настройки безопасности могут содержать брешь, через которую CA можно легко скомпрометировать. Это, например, совмещение роли CA с другими ролями, как контроллер домена, сервер терминалов, файл-сервер и т.д. В данных случаях получить доступ к закрытому ключу CA будет проще, чем в остальных сценариях.

Если выделить отдельный сервер, член домена, под роль CA, то риск снижается, но незачительно, поскольку любой член групп Domain/Enterprise Admins, операторы бэкапа, etc. могут получить доступ к ключу CA. Это весьма неиллюзорная угроза, поскольку обидевшийся админ может поломать вам единственный корневой CA и даже использовать его ключ в корыстных целях — выпускать «липовые» сертификаты. Учитывая, что не существует идеальной ОС и в любой из них обнаруживаются те или иные уязвимости, при помощи которых злоумышленник может положить ваш CA не слезая с подругидивана просто запустив эксплоит (я надеюсь, что случай с конфикером/кидо напоминать не надо?). Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес, поскольку мигрировать в другой домен/лес может быть весьма проблематично. И если вы решили переименовать домен или мигрировать в другой лес, то неиллюзорный секс с миграцией PKI вас ожидает, особенно, если всё делалось простым Next-Next. Это означает, что даже в условиях сети на 20 человек, держать корневой CA постоянно в сети — не самая лучшая идея. Хотя, если у вас есть HSM (Hardware Security Module), то опасность компрометации такого CA снижается, но не на столько, чтобы оправдать наличие корневого CA в доменной сети. Да и цена таких девайсов явно не по карману компаниям малого и среднего бизнеса. Лично мне с HSM поработать не довелось.

Следовательно, чтобы избежать всех этих проблем путь есть только один — вынос корневого CA из домена на отдельный сервер рабочей группы. При этом вы можете не покупать Enterprise редакции Windows Server, поскольку в рабочей группе хватает Standard Edition (а с выходом Winows Server 2008 R2, Standard тянет даже на Enterprise CA). Какие преимущества вы получите от такого CA?

• Резко уменьшается количество людей, которые могут получить доступ к серверу (как физический, так и программный);
• В рабочей группе вы никак не привязаны к имени домена/леса. Что позволяет сохранять корень доверия даже при смене лесов;
• В рабочей группе сервер не обязательно должен быть подключён к сети. А лучше вообще не подключать к сети, в результате чего вероятность атаки с использованием уязвимости резко падает до нуля;
• Вы можете сделать Offline CA, который будет включаться только для того, чтобы обновить свои CRL, выдать сертификат новому подчинённому CA или обновить свой собственный сертификат. Учитывая, что корневой CA выдаёт сертификаты только другим CA, поэтому вероятность необходимости отзыва такого сертификата не очень высока. Это позволяет увеличить срок действия CRL до нескольких месяцев. Здесь главное — не переусердствовать и делать срок действия CRL более 3-х месяцев вряд ли будет разумным.

С учётом выской популярности и доступности систем виртуализации, даже если у вас нет лишнего железа для сервера CA (а CA к ресурсам крайне нетребователен и может спокойно работать на железе уровня Pentium III), то вы с лёгкостью можете развернуть корневой CA на виртуальной машине с минимальной затратой средств. При этом виртуальную машину лучше хранить на съёмном жёстком диске, который можно прятать в сейф.

Policy CA — что это и зачем оно нужно?

Это достаточно большой и очень теоретический вопрос. В действительности Policy CA от остальных отличает только активная кнопка Issuer Statement:

К сожалению очень многие компании забивают на такую мелочь. Подумаешь, есть кнопка или нет её. Но в действительности Policy CA очень нужен, поскольку кнопка Issuer Statement ведёт на CPS данной ветки иерарахии CA. Как я уже говорил, CPS документально описывает порядок работы служб сертификации и сопутствующих механизмов. В RFC 3647 вы можете более подробно ознакомиться с содержимым CPS или просто почитать CPS коммерческих CA, например, VeriSign — http://www.verisign.com/repository/cps. И это не просто бумажка какая-то, а уже юридический документ, за нарушение условий которого можно получить конфет пизденцовнанести сильный ущерб доверию компании со стороны самих сотрудников и внешних партнёров. Поскольку компания может вырасти или могут поменяться условия работы, не рекомендуется совмещать роль Policy CA с ролью корневого CA, потому что корень у вас только один, а политик сертификации может быть несколько. Все последующие CA (если есть) будут подчиняться политике самого первого Policy CA в цепочке. Поэтому каждый CA второго уровня (следом за корнем) будет представлять своё дерево политик сертификации со своим CPS.

Если Policy CA не рекомендуется совмещать с корнем, то совмещать его с Issuing CA вполне можно, если у вас планируется только один Issuing CA. Если же их будет больше одного, то Policy CA следует выносить отдельно и предусмотреть для него такие же правила размещения, как и для Offline Root CA (об этом я рассказывал чуть выше). Почему не рекомендуется совмещать Policy CA и Issuing CA, если издающих будет больше одного? Дело в том, что у вас не должно быть больше одного уровня издающих CA. Т.е. вот такой схемы:

Поскольку в этом во-первых нет необходимости и вы почём зря удлиняете цепочку сертификации. В принципе, иерархии состоящие из более, чем 4-х уровней нежизнеспособны, поскольку CCE (Certificate Chaining Engine) каждый раз будет тратить очень много времени на построение и проверки цепочек сертификатов и из-за таймаутов может давать битые цепочки. Конечно же, за такое вас никто бить по лицу ногами не будет, но таких схем лучше избегать за исключением очень сложных схем, когда используется 2 уровня Policy CA (что подразумевает несколько различных политик сертификаций) и 2 уровня издающих CA. Такое возможно только в больших компаниях и их я не затрагиваю в данном материале. В случае если вам необходимо иметь несколько издающих CA под одним Policy CA, то схему лучше строить вот так, в зависимости от количеста издающих CA:

В первом случае у нас будет простая иерархия с единственным издающим CA, который так же выполняет роль Policy CA и ниже по иерархии ничего нет. Если ВНЕЗАПНО появятся потребности в ещё одном издающем CA, то это решается достаточно путём миграции ко второй схеме. Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Просто при миграции нужно учитывать несколько нюансов и всё. Поэтому с учётом перспективы целесообразно делать такую схему изначально. По большому счёту это наиболее распространённые схемы иерархий PKI.

Время жизни сертификата CA

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

• конечный сертификат — 3 года;
• Issuing CA — 5 лет;
• 2 Level Policy CA — 10 лет;
• 1 Level Policy CA — 15 лет;
• Root CA — 20 лет.

Т.е. если у вас 2-х уровневая иерархия PKI, то Issuing CA будет на 5 лет, а Root CA на 10 лет. Для 3-х уровневой иерархии Issuing CA на 5 лет, Policy CA на 10 лет и Root CA на 15 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.

Как бы и всё. Данный материал в основном опирается на общие рекомендации и моё личное восприятие этого мира, поэтому готов обсудить альтернативные варианты.

В последнее время мне всё чаще стали задавать вопрос, что выбрать, AppLocker или старый добрый SRP?

Казалось бы, что тут думать — AppLocker и точка. Многие, наверное, помнят пиар-акцию под названием «Windows 7 + 1», которую проводили многие MVP для рекламы новых технологий Windows 7. И весьма досадно то, что некоторые MVP вместо раскрытия реальной объективности новых технологий распространяли просто маркетинговый булшит и даже подтасовывали факты. Например статья Владимира Безмалого про AppLocker:

• AppLocker как средство обеспечения информационной безопасности
• AppLocker Часть 2

Этот вариант статьи можно ещё прочитать и здесь: http://www.osp.ru/win2000/2009/09/10721226/. Моё внимание обратила на себя табличка сравнения SRP и AppLocker. Вот она с моими комментариями:

Я думаю, что ни для кого не секрет, что аудит в SRP был и не сильно хуже, чем в AppLocker. Разница лишь в том, что AppLocker пишет в свой собственный EventLog, а SRP писал аудит в текстовый файл.

На счёт мастера создания правил я немного не понял. В принципе, окно создания правила в SRP тоже своего рода мастер. Только одношаговый, в отличии от AppLocker.

А сообщения об ошибках в SRP были тоже. Как в виде диалогоых окон, так и в журнале Application в эвентлоге. Т.е. тут у меня 2 мнения — либо человек не работал с SRP, либо намеренно исказил факты, чтобы подкрутить популярность AppLocker'а, поскольку революции AppLocker не совершил. Ведь с появлением AppLocker мы приобрели не только удобный интерфейс, но и потеряли несколько полезных вещей, которые есть в SRP. Как я уже отмечал ранее, мы потеряли возможность самостоятельно регулировать список контролируемых расширений файлов и потеряли возможность фильтрования файлов по конкретным сертификатам. Новое правило издателя позволяет контролировать версию разрешённого приложения, но не отличает каким сертификатом подписано приложение. Да и применимость издателей такая же как и у классических правил сертификатов — т.е. низкая. К сожалению я не могу вспомнить ни одно бизнес-приложение (не стандартные приложения типа Microsoft Office), которое бы было подписано. Плюс невозможность использования системных переменных окружения так же усложняет создание правил в доменной среде. Эту табличку можно переделать в такой вид:

Мы видим, что преимущество AppLocker перед SRP резко переходит на нет. Я не хочу сказать, что AppLocker — отстой, а лишь хочу показать, что реализация этой технологии не на столько крутая, что её стоит пиарить как революцию.

Из блога Владимира Безмалого:

В Windows 7 SRP также могут применяться, однако все чаще будет использоваться AppLocker. Почему?

К сожалению этого не случится, во всяком случае в цикле Windows 7. Как уже отмечалось, наиболее значительное изменение в AppLocker — это новый простой, удобный и понятный интерфейс, чего в SRP не было. В значительной степени из-за этого SRP на домашних компьютерах применялся лишь в единичных случаях. Сейчас же применить AppLocker гораздо проще на домашних системах при получении одинаково эффективного результата. Но Microsoft слишком жадный и включил эту технологию только в Windows 7 Ultimate и Enterprise. Я верю, что от появления SRP в домашних редакциях Windows 7 количество применений SRP на них не увеличится совсем. Учитывая, что с ноутбуками будет чаще всего проинсталлирована какая-то домашняя редакция Windows 7, то профита от AppLocker они не получат тоже. Но если дома есть возможность использовать AppLocker и вы хотите получить адекватный уровень защиты от запуска случайных файлов — используйте AppLocker. Хотя, скажите, кто из вас, кроме меня, использует Windows 7 Ultimate/Enterprise дома и использует AppLocker? :-)

Если вы будете иметь возможность перевести часть парка машин предприятия на Windows 7 Enterprise, то вопрос использования AppLocker может сложиться не в его пользу. Это обусловлено тем, что если у вас уже используется SRP, то вам AppLocker не будет нужен до тех пор, пока весь парк не будет переведён на Windows 7 Enterprise. Ведь с AppLocker вы ощутимых бенефитов не получите в плане безопасности, но сразу усложните себе жизнь тем, что вам придётся поддерживать гораздо больше политик — SRP и AppLocker. При необходимости поддерживать клиентов отличных от Windows 7 Enterprise лучше использовать то, что может охватить наиболее число машин — SRP.

Внимать моим рекомендациям — личное дело каждого, просто я отразил своё видение проблематики. Вобщем, я не верю в массовое светлое будущее AppLocker по крайней мере до выхода следующей версии Windows, даже не смотря на активный и нечестный пиар технологии со стороны Microsoft (что вполне нормально для самого создателя) и прочих пиарщиков. Но начинать его использование по мере возможности — очень даже можно и нужно, т.к. однажды SRP просто не окажется в релизе ОС.

Данный материал публикуется как обязательный для знания 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. В большинстве случаев это совершенно бесплатно (жадные дети могут радоваться :rock:) и оформить его можно, например, вот по этой ссылке: 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'ы. Если кому-то будет интересно, то можно будет посмотреть эту тему чуть плотнее.

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.

Примечание: данный материал публикуется как обязательный для знания 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.