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

• регистрация, администрирование и замена смарт-карт;
• контроль выдачи смарт-карт. Смарт-карты могут выдаваться только после собеседования с сотрудниками, которым требуются смарт-карты;
• запрос и установка сертификатов на смарт-карты;
• выдача готовой к эксплуатации смарт-карты конечным пользователям.

Для решения этой задачи Windows CA (будь то Standalone или Enterprise CA и CA может работать под управлением любой версии Windows Server) предлагает возможность реализации данной задачи через использование Enroll On Behalf Of (EOBO). Суть метода заключается в том, что такой агент получает для себя специальный сертификат на основе шаблона Enrollment Agent (или любого другого шаблона), который отвечает двум требованиям:

1. в Request Handling тип использования ключа содержит Signature;
2. в Application Policies (в прошлом Extended Key Usage или просто EKU) выставлено Certificate Request Agent.

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

После этого этот агент может запрашивать сертификаты для других пользователей. Для этого агент запускает оснастку certmgr.msc, в ней переходит на Personal –> Certificates –> Action –> All Tasks –> Advanced Operations –> Enroll On Behalf Of… и начинает процесс подачи заявки на сертификат. Во втором окне мастера агенту потребуется указать свой сертификат Enrollment Agent. Этот шаг необходим для того, чтобы доказать, что агент является Enrollment Agent'ом и данный сертификат будет использоваться для подписывания запроса сертификата. В окне выбора шаблонов вы скорее всего увидите только доступные шаблоны версии 1:

У меня есть несколько шаблонов версии 2, но запрашивать для них сертификаты я не могу. Сообщение отказа в запросе таких сертификатов весьма мутное и не очень понятное. Поскольку шаблоны версии 1 не могут быть изменены, они штатно поддерживают режим EOBO. А шаблоны версии 2 и 3 следует сконфигурировать отдельно. Для этого вам нужно открыть свойства шаблона, перейти на вкладку Issuance Requirements и отредактировать его так, чтобы он выглядел как на картинке:

Т.е. вы должны указать, что запрос должен быть подписан сертификатом, Application Policies которого содержит Certifcate Request Agent.

Вообще тут разгуляться можно как следует. При наличии специальных требований, вы можете создать определённые рабочие процессы (workflows). Например, в шаблоне сертификата Enrollment Agent, который требует хранение сертификата на смарт-карте (явно указан только CSP смарт-карты) в Issuance Policies (Certificate Policies) можете создать отдельную политику выдачи, например Smart Card Enrollment Agent, назначив этой политике свой OID. Таким образом у вас может быть 2 Enrollment Agent'а, один из которых выдаёт смарт-карты с сертификатами для цифровых подписей, а другой агент будет выдавать сертификаты смарт-карт для шифрования файлов. При этом первый агент будет хранить свой сертификат Enrollment Agent на смарт-карте, а второй в профиле пользователя. В сертификате Enrollment Agent первого агента в Certificate Policies будет указан OID, который вы присвоили политике Smart Card Enrollment Agent. Сертификат второго агента не будет содержать особых политик выдачи (используется стандартный шаблон Enrollment Agent версии 1).

Чтобы разделить шаблоны между агентами вы можете их настроить вот так:

Мы теперь требуем, чтобы сертификат агента подачи заявок не только содержал определённый Application Policy, но и Issuance Policy тоже. Это означает, что агент подачи заявок, который хранит свой сертификат в профиле не будет иметь возможности запрашивать сертификаты такого шаблона. Вот вам ещё один сценарий использования OID'ов. Это на случай, чтобы вы не думали, что это какая-то мифическая никому не нужная фигня.

Собственно, после этой настройки шаблонов версии 2 и 3 вы можете их использовать в EOBO:

Помимо этого, вы можете ещё более точно очертить возможности агентов восстановления:

Начиная с Windows Server 2008, вы можете задавать более гранулированные права для enrollment agent'ов, указывая каким агентам какие сертификаты можно запрашивать с использованием EOBO.

Данный материал не претендует на статус ТЗ (Тайное Знание), но даёт огромную пищу для размышления администраторам средних и крупным компаний на предмет того, как можно расширить возможности использования PKI и создать более чёткое разделение обязанностей агентов подачи заявок (Enrollment Agent) при использовании функции Enroll On Behalf Of (EOBO). Как вы видите, Windows PKI даже из коробки позволяет достаточно просто масштабировать и управлять вашей инфраструктурой PKI. А так же мы развеваем миф о том, что инфраструктурой PKI может рулить студент-ПТУшник (петушатник?), который поднимает CA на коленке в метро.

Для больших компаний существуют ещё более мощные и гибкие средства для выполнения подобных задач, которые есть в таких продуктах как Identity Lifecycle Manager (ILM) 2007 или в Forefront Identity Manager, но о них мы говорить не будем.

Дополнительные материалы: Что в OID'е тебе моём?

Это была реклама студентов ПТУ.

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

Мне иногда задают вопрос про сущность этой опции Enable private strong protection, а так же встречаются любители обезопасить свои ключи данной опцией. Итак, что это такое? Private key strong protection позволяет вам шифровать ваш закрытый ключ отдельным паролем и является некоторым подобием поведения, когда сертификат находится на смарт-карте. Включить данную опцию вы можете при энроллменте или импорте сертификата. При энроллменте выберите нужный вам шаблон сертификата, нажмите Properties, перейдите на вкладку Private key, раскройте Key options и поставьте галочку на Strong private key protection:

после нажатия Ok, вылезет окошко, которое потребует у вас указать степень защиты и пароль (если выбран High):

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

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

• сертификатов компьютера, которые хранятся в LocalMachine store

все сертификаты (например, SSL, IPsec), которые хранятся в компьютерном хранилище используются только учётной записью компьютера и диалоговое окошко с требованием подтвердить доступ к ключу появится у учётной записи LocalSystem, а вы не увидите этого запроса, в следствии чего сертификат невозможно будет использовать.

• для сертификатов EFS пользователей

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

1. Local Security Authority — LSA (lsass.exe) проверяет наличие сертификата EFS в профиле пользователя или на смарт-карте. Если не находит, то в зависимости от настроек политик может запросить новый сертификат у CA или сгенерировать самоподписанный. Самоподписанный сертификат генерируется если в доменной сети не зарегистрировано ни одного CA или машина находится в рабочей группе и в политиках не запрещено использование самоподписанных сертификатов EFS;
2. LSA генерирует симметричный ключ шифрования FEK (File Encryption Key) в закрытой и недоступной для пользователя области памяти;
3. LSA этим симметричным ключом шифрует сами данные;
4. LSA выбирает из профиля пользователя открытый ключ сертификата EFS и им шифрует симметричный ключ шифрования и записывает шифр в DEF (Data Encryption Field) файла.

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

1. LSA читает DEF файла и выясняет Thumprint сертификата, который использовался при шифровании симметричного ключа (FEK);
2. LSA пытается взять закрытый ключ от сертификата, но его ожидаем облом. Закрытый ключ зашифрован паролем, который известен только пользователю. Т.к. lsass.exe — это системный процесс и работает в закрытой области памяти, не представляется возможным (по условиям безопасности) передать окно для ввода пароля в сессию пользователя. Просто это наиболее короткий путь к повышению своих привелегий :-)

Поэтому окошка вы никакого не видите и, следовательно, доступ к данным сразу же теряете. Чтобы избежать этого было сделано хорошее решение — не шифровать файлы вообще, если сертификат EFS защищён отдельным паролем и запросить/сгенерировать новый сертификат не представляется возможным. Т.е. на стадии 1 LSA попутно проверяет статус закрытого ключа. И если он защищён, то пробует запросить новый сертификат EFS для пользователя. Если CA недоступен или нет шаблона Basic EFS, то пытается сгенерировать самоподписанный. Если политиками запрещено использовать самоподписанные сертификаты EFS, то получаете ошибку и никакого шифрования не производится.

Нужен ли этот Strong protection в реальной жизни? В реальной жизни есть смысл использовать смарт-карты, тем более сейчас всё больше приложений поддерживают их. И EFS в том числе. Тогда strong protection можно отключить на уровне политик:

Computer Configuration –> Policies –> Windows Settings Security Options –> System Cryptography: Force strong key protection for user keys stored on the computer

Если не уверены, что оно вам надо, то лучше отключить эту возможность на уровне домена. Включать эту политику не рекомендуется, поскольку она может привести к катастрофическим последствиям, что сертификаты у вас просто перестанут работать.

Update 04.01.2010: исправлена неточность в тексте. CRL'ы из CDP контейнера AD не копируются на клиентские компьютеры.

В предыдущей статье: Обсуждение схем иерархии Certification Authority мы обсудили наиболее часто встречающиеся ошибки при дизайне иерархии CA. Если кто-то захочет перевести как минимум корневые Enterprise CA на Standalone CA и сделать их Offline, то в этом посте вы узнаете как это делается пошагово.

Изначальные условия:

• onlineca.adatum.com — DNS имя компьютера в домене/лесу adatum.com с установленной ролью Enterprise CA, которую планируется перенести на Standalone CA. Имя CA — Adatum Root CA;
• OfflineRCA — NetBIOS имя компьютера в рабочей группе. Этот компьютер будет держать роль Standalone Root CA для домена/леса adatum.com.

Предварительная переконфигурация

Перед переносом текущего корневого и/или Policy CA следует заранее спланировать периодичность публикации CRL. Если Enterprise CA, как правило, публикует Base CRL каждые 7 дней и Delta CRL — каждые 24 часа. Для Offline CA такая конфигурация будет неработоспособна. Поэтому мы должны переконфигурировать следующие параметры:

• Отключение публикации Delta CRL;
• Увеличение срока действия Base CRL;
• Настройка Overlap Settings.

Для этого мы можем применить вот такой Reg файл:

Примечание: Статья содержит сведения о внесении изменений в системный реестр. Перед внесением изменений в системный реестр рекомендуется создать резервную копию системного реестра и изучить процедуру его восстановления. Дополнительные сведения о создании резервной копии, восстановлении и изменении реестра см. в статье базы знаний Microsoft: http://support.microsoft.com/kb/256986/.

Windows Registry Editor Version 5.00

                                                                                   Root CA]
"CRLPeriod"="months"
"CRLPeriodUnits"=dword:00000003
"CRLOverlapPeriod"="weeks"
"CRLOverlapUnits"=dword:00000001
"CRLDeltaPeriod"="Days"
"CRLDeltaPeriodUnits"=dword:00000000
"CRLDeltaOverlapPeriod"="hours"
"CRLDeltaOverlapUnits"=dword:00000000
"CAXchgValidityPeriod"="Weeks"
"CAXchgValidityPeriodUnits"=dword:00000000
"CAXchgOverlapPeriod"="Days"
"CAXchgOverlapPeriodUnits"=dword:00000000
"ValidityPeriod"="Years"
"ValidityPeriodUnits"=dword:00000005

Этим файлом мы задаём срок действия Base CRL в 3 месяца (но этот период может быть и другой, в зависимости от местных условий) с overlap равным 1 неделя. Так же отключили использование Delta CRL и CA Exchange, который используется для архивирования ключей в базе CA. А так же установили срок действия конечных сертификатов в 5 лет. Если под этим CA будет выделенный Offline Policy CA, то это значение может быть изменено на 10 лет. После импорта этого файла, вы должны перезапустить службу Certificates Services:

net stop certsvc && net start certsvc

Теперь нужно опубликовать новый CRL с новыми настройками:

certutil –CRL

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

Бэкап Certification Authority

Бэкапу будут подлежать следующие вещи:

• База CA;
• Ключевая пара CA;
• Конфигурация CA.

Примечание: на данном этапе пользователи и компьютеры уже не смогут отправлять запросы на этот CA. Но могут продолжать использовать CRL'ы для валидации сертификатов.

Первым делом нужно сделать бэкап самой базы CA. Для этого в командной строке выполните:

certutil –backup c:\RootCA_%date%

Для удаления ключевой пары запустите консоль MMC и добавьте в ней оснастку Certificates с указанным контекстом Computer Account. В оснастке раскройте секцию: Personal –> Certificates и найдите текущий сертификат CA. Далее, Action –> All Tasks –> Export. На странице Export Private Key мастера экспорта сертификатов переставьте переключатель в Yes, export private key. На странице Export file format поставьте галочки напротив Delete the private key if the export is successful и Export extended properties. Этим самым мы удаляем закрытый ключ CA с данного сервера, поскольку он больше не нужен и для предотвращения несанкционированного доступа к ключу. Установите пароль на PFX файл и сохраните в него экспортируемый сертификат. После экспорта удалите этот PFX файл.

Примечание: экспорт сертификата в PFX нужен только для удаления с сервера закрытого ключа CA. Сам ключ был сохранён во время бэкапа базы CA.

Теперь у нас в корне диска C: будет храниться полный бэкап базы CA и его ключевая пара. Нам осталось выполнить бэкап конфигурации CA. Для этого откройте редактор реестра и установите курсор на ключе:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Adatum Root CA

Экспортируйте этот ключ в Reg файл и сохраните в папке, где расположен бэкап базы CA. После этого перенесите всю папку бэкапа на съёмный носитель и скопируйте в корень диска C: компьютера OfflineRCA.

Демонтаж Enterprise CA

Теперь мы готовы демонтировать наш Online Enterprise Root CA. Для этого запустите Server Manager (для 2008 и выше) или Add or Remove Programs –> Windows Components (для 2003) и удалите с сервера роль CA.

После демонтажа роли убедитесь, что данный CA больше не отображается в AD как Issuing CA. Для этого можете запустить оснастку ADSIEdit.msc в контексте Configuration. И пройдите по пути: Configuration –> Services –> Public Key Services –> Enrollment Services. Если демонтируемый CA отсутствует внутри этой папки, то можете закрыть консоль. Если всё ещё отображается, то удалите запись данного CA и закройте ADSI Editor.

Примечание: для удаления объектов PKI из AD вам потребуются права Enterprise Admins.

Установка Offline Standalone CA

На данном этапе все манипуляции будут производиться на сервере OfflineRCA, который состоит в рабочей группе. Запустите Server Manager (или Add or Remove Programs –> Windows Components для 2003) и поставьте галочку на Active Directory Certificate Services (или Certification Authority для 2003). Я думаю, что мастер вам уже знаком, поэтому я только расскажу на каких страницах мастера нам потребуется сделать изменения. В принципе, можете двигаться Next->Next до страницы Private Key. На этой странице выберите Use existing private key и Select a certificate and use its associated private key. Нажмите Next и нажмите кнопку Import. Импортируйте закрытый ключ вместе с сертификатом из PFX файла, который находится в папке с бэкапом CA. На следующей странице можете задать папки хранения базы CA.

Примечание: вам не обязательно устанавливать Standalone CA на полный сервер, а лучше будет устанавливать в Server Core.

Когда роль CA установлена, мы должны восстановить базу CA и конфигурацию. В командной строке выполните:

certutil –restore c:\RootCA_%date% –f –config "OfflineRCA\Adatum Root CA"

и конфигурацию восстановить простым запуском Reg файла. Если ваш бывший корень публиковал сертификаты и CRL в LDAP, то теперь мы не сможем это делать напрямую. Чтобы исправить это, откройте оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. В ней найдите и удалите все LDAP ссылки в CDP и AIA, которые связаны с вашим доменом.

Всё, теперь мы полностью перенесли Online Enterprise Root CA на Offline Standalone CA, который теперь может выключаться на очень большие промежутки времени. По сути это потребуется только для того, чтобы опубликовать новый CRL, издать новый сертификат подчинённому CA или обновить свой собственный сертификат. Ну и обновления на сервер ставить тоже надо невзирая на то, что сервер будет большую часть времени выключен.

Включение распознавания Offline CA в лесу

Чтобы наш мигрированный CA распознавался в исходном домене/лесу adatum.com, нам нужно опубликовать его сертификаты в следующих контейнерах Active Directory:

• Certification Authorities — данный контейнер используется для организации доверия корневым CA в текущем лесу. Данные сертификаты автоматически копируются в контейнер Trusted Root CAs всех компьютеров в лесу;
• AIA — данный контейнер используется для публикации Subordinate (или Intermediate) CA. Это позволяет сократить время на построение цепочек сертификатов. Сертификаты из данного контейнера автоматически копируются в Intermediate CAs на каждый компьютер в текущем лесу;
• CDP — данный контейнер используется для публикации любых CRL. Чуть ниже я расскажу, как вы будете его использовать. Содержимое данного контейнера не копируется клиентам и будет использоваться только в случае, если какой-то сертификат явно ссылается на CRL в этом контейнере.
• CN = NTAuthCertificates — это запись внутри контейнера Public Key Services. Данная запись содержит сертификаты тех CA, которые выдавали логонные сертификаты. Это относится как к логонным сертификатам для смарт-карт, сертификатам для аутентификации в IIS и VPN.

Для импорта сертификата CA войдите в домен с правами Enterprise Admins, скопируйте открытую часть сертификата в C:\RootCA.cer, запустите командную строку и выполните:

certutil –dspublish –f c:\RootCA.cer RootCAcertutil –dspublish –f c:\RootCA.cer SubCAcertutil –dspublish –f c:\RootCA.cer NTAuthCA

После того, как пройдёт репликация в лесу, наш новый CA будет полностью распознаваться как доверенный в текущем лесу.

Установка Online Enterprise Issuing CA

Теперь можно приступать к процессу установки Enterprise Subordinate CA, который уже будет обслуживать конечных потребителей. Единственная разница в установке будет в том, что в списке ролей CA вы должны выбрать Enterprise Subordinate CA.

Совет: при установке CA старайтесь избегать привязки к домену в distinguished name CA. Используйте только привязку к названию компании, например:

CN = Adatum Class 1 Public Primary Certification Authority
OU = DB management systems
O = Adatum Inc.
C = US

Сохраните запрос в файл и получите сертификат у вышестоящего Offline CA (корневого или policy). Этот вопрос выходит за рамки данного материала, поэтому рассматриваться не будет. Сконфигурируйте CA должным образом (точки распространения сертификатов, CRL, периодичность публикации CRL, шаблоны, etc.) и можете запускать его в работу.

Offline CA CRL lifecycle

В случае, если ваш Enterprise CA до миграции публиковал LDAP ссылки в сертификатах, то для избежания задержек при проверке сертификатов, вы в течении всей жизни текущего сертификата корневого и/или Policy CA должны поддерживать доступность CRL в этих точках. Поскольку наши Root и Policy CA теперь члены рабочей группы и не могут публиковать CRL прямо в AD, вам придётся заниматься этим вручную. Когда Offline CA опубликует новый CRL, вы должны его доставить (по сети, что не очень рекомендуется, или через съёмные носители) в точки, куда он публиковался раньше (чтобы обеспечить работоспособность расширений CDP/AIA сертификатов). Если с HTTP ссылками всё просто (положили файл на веб-сервер и всё), то с LDAP придётся делать чуточку иначе, а именно — публиковать его в AD в контейнер CDP:

certutil –dspublish –f C:\RootCA.crl "Adatum Root CA"

Ещё раз обращаю ваше внимание на то, что эта операция требует права Enterprise Admins.

Кажется ничего не забыл. Но если что-то забыл — напомните.

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 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.

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

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