Краткое руководство по Microsoft PKI

Written on 05 Декабря 2008. Posted in Администрирование Windows

В этой статье, состоящей из трех частей, я кратко расскажу вам, как устанавливать, проектировать и отлаживать PKI (Public Key Infrastructure – инфраструктуру открытого ключа) с помощью служб сертификатов Microsoft Certificate Services в операционной системе Windows Server 2003. Я расскажу вам о наиболее часто встречающихся подводных камнях, а также о лучших рекомендациях по построению и работе с PKI на платформе Microsoft, а также сфокусируюсь на основах построения правильной и гибкой PKI с самого начала.

Для чего вам нужна PKI

Несколько лет назад все говорили о 2000 годе, как о годе PKI. Многие верили, что основной рынок был, наконец, готов воспользоваться всеми теми преимуществами, которые могла предложить PKI. Однако, как вы, вероятно, догадались, сертификаты и PKI в действительности не пользовались особой популярностью. Это было просто недостаточно сексуально в управлении для прессы и технического персонала (которые одновременно являлись единственными людьми, которые могли увидеть значимость PKI). Однако, по прошествии времени PKI снова стала одной из самых горячих тем, как для большого, так и для среднего бизнеса, хотя в этот раз мы можем наблюдать менее амбициозный и более реалистичный подход к использованию сертификатов (certificate) и PKI среди администраторов IT и людей, принимающих бизнес решения. Сдвиг в сторону безопасности, когда безопасность и усовершенствование Интернет и технологий мобильных коммуникаций стали частью работы многих компаний, означает, что сертификаты и PKI более готовы для основного рынка бизнеса в настоящее время, чем когда-либо ранее.

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

Шифрование диска и файлов (сертификаты используются для защиты симметричного крипто ключа symmetric crypto key)
Многофакторная аутентификация (Multifactor authentication) с помощью смарт карт
IPSec
Цифровая подпись (Digital signature)
Аутентификация RADIUS и 802.1x authentication
Беспроводные сети (Wireless networks)
NAP (Network Access Control) и NAQ (Network Access Quarantine) соответственно для подписи кода и драйверов
SSL/TLS для защиты HTTP трафика

Как вы видите, сертификаты используются во многих местах, и их основное назначение для усиления безопасности вашей инфраструктуры и решений IT. Но если вы посмотрите на наш список, представленный выше, то сможете представить, что необходимо управлять большим количеством сертификатов, в зависимости от того, какими преимуществами вы хотите воспользоваться в своей инфраструктуре, и как вы захотите их реализовать. Именно тут вам и может помочь PKI. PKI – это просто способ центрального управления, выпуска, обновления и аннулирования сертификатов, а также способ построения вашего маршрута доверия. Сертификаты и PKI, о которых мы расскажем в этой статье работают на X.509 v3, что значит, мы можем разносторонне использовать сертификаты, что мы и рассмотрим подробнее во второй части этой статьи.

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

Планирование PKI

Итак, я соглашусь, что при знакомстве с фазой планирования в нашей первой статье, мы еще не обладаем достаточным багажом технических знаний, на который вы может быть надеялись. Но кроме всего прочего, фаза планирования очень важно, и мы расскажем вам о том, как пройти эту фазу с минимальными усилиями, показав вам области, на которых вам стоило бы сфокусироваться. Самую частую ошибку компании допускают при установке служб сертификатов Microsoft Certificate Services (и таким образом устанавливают PKI), и она заключается в том, что они игнорируют фазу планирования, в результате чего им приходится потратить гораздо больше ресурсов и денег, когда понимают, что упустили из виду некоторые важные проблемы, когда перешли к меню Add/Remove Windows Components на своем сервере с операционной системой Windows 2000 или Windows 2003 и поставили галочку напротив компонентов служб сертификатов Certificate Services.

Области, которые необходимо рассмотреть при планировании вашей будущей PKI, следующие:

Проверить, обновляется ли ваша политика безопасности (security policy) и готова ли она для PKI
Создать одну или несколько политик для сертификатов (certificate policies)
Создать предложение для сертификата

Давайте подробнее рассмотрим все эти области

Проверьте, обновляется ли ваша политика безопасности (security policy) и приготовьтесь к PKI

Брайен Комар (Brian Komar), который является автором превосходной книги "Microsoft Windows Server 2003 PKI and Certificate Security" (смотрите ссылку в конце статьи) и который написал несколько статей для Microsoft и давал лекции по различным субъектам Microsoft PKI, часто говорит, что: "PKI усиливает политики безопасности в вашей организации". Это утверждение, на мой взгляд, очень хорошо все выражает. Убедитесь, что в вашей компании существует политика безопасности (security policy), которая направлена на бизнес и стратегию IT. Затем необходимо подготовить эту стратегию для приложений и служб безопасности, которые будут зависеть от сертификатов (certificates). Т.к. политики безопасности необходимо согласовать с управляющими или даже с главами (в конце концов, эти люди отвечают за бизнес стратегию вашей компании), то у вас зажжется зеленый цвет, и вы можете приступить к вашей реализации PKI. Если вы достаточно несчастливы, и в вашей компании нет корпоративной политики безопасности (security policy), то вы можете прейти по следующей ссылке и посмотреть примеры различных политик безопасности, включая примеры политик безопасности, которые работают по стандарту ISO 17799 standard.

Создание одной или нескольких политик для сертификатов (Certificate Policies)

Я согласен. Политике это не самая волнительная вещь в мире, но кроме всего прочего, они по-прежнему очень важны. И если вы хотите избежать всех проблем с вашей инфраструктурой PKI, то лучше правильно создать политику для сертификата Certificate Policy (CP). Политика для сертификата (certificate policy) описывает, как и кто выпускает и распределяет сертификаты для субъектов (т.е. субъектами могут быть пользователи, компьютеры, устройства и т.д.). Это может быть очень сложная задача, хотя и очень важная, но не волнуйтесь. Просто выполните шаги, представленные ниже, и вы будете на правильном пути к созданию политики сертификата для вашей PKI.

Взгляните на RFC 3647, которую вы можете найти здесь
Затем посмотрите, как должна выглядеть хорошая политика для сертификата (certificate policy), хотя эта политика, вероятно, будет более детальной, чем та, которая понадобится вам.
The X.509 Certificate Policy for the United States Department of Defense (DoD)

Создание предложения для сертификата

Мы почти закончили с этапом планирования, но нам все еще нужно создать предложение Certificate Practice Statement (CPS). Это предложение CPS очень похоже на политику для сертификата Certificate Policy, за исключением того, что она фокусируется на безопасности полномочий сертификатов Certificate Authority (CA) во время операций и управления сертификатами, выпущенных CA. CPS обычно гораздо короче, чем политика безопасности Security Policy и содержит информацию относительно того, кто отвечает в случае, если сертификат не может адекватно защитить то, что он должен защищать. Примером может служить безопасное соединение SSL/TLS, если пользователь вводит номер своей кредитной карты. Другие области (как минимум), которые должны быть включены в CPS – это как обрабатывается проверка, обновление и аннулирование CA, ответственным за выпуск сертификатов. Вы можете рассматривать CPS, как соглашение между пользователем сертификата и компанией, которая отвечает за выпуск CA. И как вы уже могли догадаться, у нас есть несколько великолепных примеров для CPS, которая может показаться вам знакомой.

Точно также, как в случае с политикой сертификатов Certificate Policy, вы можете посмотреть на информацию RFC 3647 для CPS, которую вы можете найти здесь
И для вдохновения, посмотрите на VeriSign CDP здесь

В отличие от политики сертификатов Certificate Policy, CPS необходимо всегда делать общедоступной, чтобы пользователь сертификата всегда имел доступ к CPS. В каждом сертификате, выпущенном вашей CA должны быть ссылка, которая указывает место, где опубликовано CPS.

Проектирование PKI

Когда вы проектируете ваш PKI, то необходимо учитывать следующие вещи:

Как должен выглядеть ваша иерархия CA (в том числе количество CA, и их роли)
Как вы собираетесь защищать закрытые ключи (private key) CA
Где вы будете создавать точки публикации

Давайте поближе посмотрим на каждую из этих проектных проблем.

Проектирование иерархии CA, которая хорошо масштабируется

Количество и уровни CA вы должны учитывать сразу, в зависимости от ваших требований к безопасности и доступности. Вы должны постараться организовать вашу иерархию в соответствии с вашими нуждами. В действительности не существует каких- либо рекомендаций относительно того, сколько уровней CA вам нужно, хотя очень редко кому-либо необходимо 4 или более уровней. Однако, существует правило большого пальца, которое мы представили в таблице 1 ниже, которое здорово поможет вам идти в верном направлении:

Таблица 1: Количество необходимых уровней CA
Уровень CA	Комментарии
	Низкая безопасность (Low security) Сниженные требования к безопасности CA Состоит из одного корневого CA Небольшое количество запросов сертификатов
	Средняя безопасность (Medium security) Состоит из автономного (offline) корневого и оперативных (online) второстепенных CA Автономный CA удаляется из сети Оперативные CA остаются в сети Рекомендуется использовать два или более CA для выпуска каждого шаблона для сертификата
	Высокая безопасность (High security) Состоит из автономного корневого (offline root) и автономной политики (offline policy) Один или более выпускающих оперативных дополнительных CA Подходит для больших географически разнесенных организации

Как дополнительное примечание, вы можете вспомнить из предыдущей статьи, что существует нечто, называемое политикой сертификата (certificate policy), которая описывает как и кто будет выпускать и распределять сертификаты для субъектов (субъекты – это пользователи, компьютеры, устройства и т.п.). Если вам кажется, что вам может понадобиться более одной политики сертификата (certificate policy) из-за правовой, географической организационной особенности, то вам определенно нужна трехуровневая иерархия PKI hierarchy, т.к. для соблюдения этого требования необходимо 2 или более политики CA второго уровня.

Когда вы реализуете PKI, вы всегда должны начинать с корневого (root) CA, вне зависимости от того, имеем ли мы дела с одноуровневой, двухуровневой или трехуровневой иерархией PKI hierarchy. Т.к. корневой (root) CA всегда будет в основании доверительных отношений (trust), и очень часто реализуется с использованием самовыпускающегося сертификата (self-issued certificate), то очень важно защищать закрытый ключ (private key) вашего корневого (root) CA всеми доступными способами. Так должно быть всегда, вне зависимости от количества уровней, из которых состоит ваша иерархия PKI. Если ваша иерархия PKI состоит из 2 или более уровней, то для вашего корневого (root) CA необходим минимальный доступ, т.к. к корневому CA будет необходим доступ только для второстепенного CA. Однако, по мере того, как увеличивается расстояние до корневого (root) CA (т.е. увеличивается количество уровней), требования к безопасности снижаются и доступ увеличивается. Это очень важный фактор, когда мы начнем установку CA, о котором мы расскажем позднее в этой статье.

Закрытые ключи CA (private key)

Перед тем, как вы начнете установку CA, вы должны спланировать, какой будет размер закрытого ключа (private key) для CA, а также, как он должен быть защищен. Давайте посмотрим на размер ключа, который является очень важным по причине безопасности и совместимости. В таблице 2 ниже представлены рекомендуемые размеры ключей:

Таблица 2: Рекомендованный размер ключа CA
CA роль	Размер ключа
Root CA (корневой)	4096
Policy CA (политика)	4096
Issuing CA (выпускающий)	2048

Обычно, целях безопасности рекомендуется использовать ключ размером 4096, особенно для корневого (root) CA. Однако, в результате этого могут возникнуть различные проблемы с совместимостью, примером могут служить сетевые продукты компании Cisco (в зависимости от используемой версии Cisco IOS). Это возникает в результате того, что многие продукты сторонних производителей имеют проблемы с обработкой ключа, размер которого больше 2048. А т.к. сетевое оборудование может быть интегрировано в решения, как 802.1x для проверки и совместимости, размер ключа имеет значение. Поэтому необходимо быть абсолютно уверенными, что вы знаете используемое вами оборудование, а также его ограничения для обработки сертификатов перед тем, как вы начнете реализовывать ваш PKI.

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

Защита закрытого ключа CA

По умолчанию, CA использует поставщика услуг по шифрованию Microsoft Cryptographic Service Provider (CSP) и защищает свой закрытый ключ (private key) с помощью встроенного программного интерфейса для защиты данных Data Protection API (DPAPI). В результате этого возникает проблема, т.к. все члены группы локальных администраторов (local administrators group) имеют доступ к закрытому ключу CA, и любой член этой группы может экспортировать закрытый ключ CA, а затем создать фальшивый CA, который сможет выпускать фальшивые сертификаты. Еще одна проблема с безопасностью заключается в атаках с переполнением буфера (buffer overrun) с помощью вредоносного программного обеспечения.

Итак, что же делать? Самый лучше ответ – это зависит от… Вам придется выбирать между требованиями к безопасности и стоимостью и удобством, связанными с защитой закрытого ключа (private key) CA, и очень часто иерархия CA диктует свои правила. Ниже в таблице 3 приведены некоторые из наиболее общих способов для защиты закрытого ключа (private key) CA. Мы оставим это на ваше собственное усмотрение. Просто помните, что это, вероятно, один из самых важных компонентов в вашем PKI.

Таблица 3: Некоторые наиболее частые способы защиты закрытых ключей CA
Метод защиты	Pros (+)	Cons (-)
Local Certificate Store (локальное хранилище)	Прост в использоварнии (по умолчанию) Низкие затраты	Низкая безопаность Встроен только в CSP Совместим только с FIPS 140-1
Chip based authentication (чиповая аутентификация - Смарт карты или USB ключи)	Прост в использовании Низкие затраты FIPS 140-2 compliant	Низкая физическая безопасность, т.к. смарт-карту легко можно потерять или украсть Требует физического присутствия для запуска службы Certificate Services Требует специального CSP, который совместим с FIPS 140-2 и поддерживает службы сертификатов Microsoft Certificate Services
Encrypted Virtual machines (зашифрованные виртуальные машины)	Прост в использовании Низкие затраты Не зависит от аппаратного обеспечения Совместим с FIPS 140-2	Средняя безопасность Уязвим к аналоговым атакам, т.к. жесткий диск или DVD, на котором содержится виртуальная машина можно легко украсть или потерять
Hardware Security Module (HSM - аппаратные модули безопасности)	Очень высокий уровень безопасности Совместим с FIPS 140-2 второго и третьего уровня Может использовать в качестве основы PCI или LAN Можно также часто использовать как ускорители SSL	Большие затраты (в зависимости от конфигурации) Требует осторожного и внимательного планирования

В дополнение к рекомендациям, представленным в таблице 3, вы также можете увеличить безопасность CA, убедившись, что все CA, за исключением выпускающего CA, работают в автономном режиме (offline). Под этим мы понимаем, что они должны быть вне сети и подключаться к сети лишь тогда, когда для CRL и выпущенным сертификатам для всех CAs во всем PKI необходимо обновление. Обычно, корневой и стратегический CA выключаются полностью, но опять же это зависит от того, насколько хороша у вас физическая безопасность, и как защищаются закрытые ключи CA private keys, а также насколько надежно ваше аппаратное обеспечение.

Где создавать точки публикации

Последняя область, на которую мы обратим внимание перед тем, как начнем реализацию PKI, это размещение публикации для списков Certificate Revocation Lists (CRL) и общих ключей (public key) CA. Их также называют точки размещения сертификатов (Certificate Distribution Points или CDP). Существуют различные протоколы, которые можно использовать для описания CDP. Это:

HTTP
LDAP (под которым обычно подразумевают Active Directory)
FTP
File share (SMB)

Ниже на рисунке 1, мы изобразили, где публиковать CRL и открытые ключи CA (public key), а также рекомендуемый порядок протоколов.

Рисунок 1: Рекомендуемый порядок протоколов для CDP

Как вы можете увидеть, основной рекомендуемый протокол – это HTTP, и на это есть очень важная причина. Рекомендуется использовать HTTP, т.к. это лучший протокол для внутренних и внешних точек публикации. HTTP великолепен, если вам необходимо одновременно выпускать протоколы для внутренних и внешних пользователей. Особенно важно рассмотреть внешнее использование, т.к. вы должны быть уверены, что сертификаты, используемые для доступа к VPN, NAQ или Wi-Fi проверены на аннулирование до того, как пользователям будет разрешен доступ к внутренней сети. Очень важно обратить внимание, что если CDP не доступен для какого-то протокола, то по прошествии тайм-аута (обычно после 30 секунд), мы переходим к следующему протоколу из списка. Таким образом, если у вас с самого начала правильная конфигурация, вы заслуживаете доверие пользователей, т.к. CRL можно проверить для внутренних и внешних размещений без проблем с тайм-аутом, и не подвергая опасности установки вашей сети. Однако, если в том или ином случае вы должны выбрать протокол по умолчанию, которым является LDAP, то в этом нет ничего плохого, особенно, если ваш PKI планируется использовать для внутреннего пользования. Просто знайте, что если вы используете PKI, интегрированный в Active Directory и выпускаете сертификаты для внешних пользователей, то необходимо, чтобы они смогли выполнять LDAP запросы к вашей Active Directory (предполагается, что вы используете Active Directory в качестве хранилища для CDP LDAP).

Однако, вы также должны убедиться, что у вас установлен избыточный веб сервер, использующий DNS, если вы предпочитаете использовать протокол HTTP. Если вы хотите использовать LDAP, то вы у вас уже есть избыточная установка, если в вашем домене более одного контроллера домена.

Установка PKI

Основываясь на некоторых знаниях об оформлении, полученных из предыдущих частей, пришло время начать установку вашего PKI. Так как это краткое руководство, мы рассмотрим сразу несколько вещей, потому что они принадлежат к оформлению. Также мы покажем вам, как установить 2-х уровневую иерархию, состоящую из отключенного корневого Certificate Authority (CA) и включенного «выпускающего» CA в том же PKI, использующем наилучшие практические методы. Однако прежде, чем мы начнем установку, давайте объясним кое-что на практике.

На Рисунке 1 мы проиллюстрировали наилучшее применение периода допустимости для каждого CA на каждом уровне (базирующегося на 3-х уровневой иерархии для полного обзора). Преимуществом этой модели является то, что она будет всегда гарантировать вам совместимость «выпускаемых» сертификатов на каждом уровне. Если вы только хотите использовать 2- уровневую иерархию, просто переместите CA на уровень 3. Модель все еще будет использовать.

Рисунок 1: Наилучшее применение периода допустимости для каждого CA на каждом уровне

Еще вам следует подготовить текстовый файл CAPolicy.inf прежде, чем мы начнем установку. Этот файл используется для управления вашими настройками сервиса сертификатов Windows. В этом файле, вы найдете такие важные вещи, как:

CDP оператор
Обновленные установки сертификата, такие как период допустимости и размер ключа
Каналы связи для CDP и AIA маршрутов
Как часто следует публиковать CRL

Создайте файл, используя Notepad и сохраните его в %windir%\capolicy.inf (например, C:\Windows\capolicy.inf).

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

Установка отключенного корневого CA

Чтобы установить отключенный корневой CA, вам нужно выполнить следующие операции:

Подготовить файл CAPolicy.inf
Установить сервис сертификатов Windows
Опубликовать список CRL
Запустить пост-настроечнный командный файл

Вот как вы можете сделать это:

Установить сервер с Windows Server 2003 Standard Edition, включая SP1 или более свежие версии и убедиться, что он запущен как автономный сервер (например, он не должен быть элементом никакого домена)
Make the necessary parameter replacements in the CAPOlicy.inf file below (highlighted with red) Сделать необходимые замены параметров в файле CAPOlicy.inf, приведенном ниже (выделены красным цветом)

Рисунок 2: Имя файла: CAPolicy.inf
Копировать файл CAPolicy.INF в %windir%\capolicy.inf
Пройти по Start Menu / Control Panel / Add or Remove Programs |нажать на Add/Remove Windows Components
В Windows Components Wizard, вы выбираете Certificates Services и нажимаете Next
Обратите внимание на окно сообщений. Вы не должны переименовывать компьютер, раз установлены сервисы сертификата Windows. Нажмите Yes

Рисунок 3
В поле типа центра сертификации нажмите Stand-alone root CA, и поставьте галочку напротив “Use custom settings to generate the key pair and CA certificate” и нажмите Next
Примечание: Это нормально, что опции Enterprise root CA и Enterprise subordinate CA не могут быть выбраны, так как этот сервер не является элементом домена.

Рисунок 4
Выберите CSP, который вы хотите использовать для вашего отключенного корневого CA. Для простоты мы выбрали Microsoft Strong Cryptographic Provider v1.0, однако, вы также можете выбрать другой CSP, если вы, например, установили Hardware Security Module (HSM) и соединились с сервером через HSM, прежде чем вы начали процедуру установки.
Выберите по умолчанию хешированный алгоритм SHA-1

Установите длину ключа 4096

Убедитесь, что обе опции “Allow this CSP to interact with the desktop” и“Use an existing key” не выбраны. Нажмите Next

Рисунок 5
Введите полное имя для вашего корневого CA, настройте суффикс отличительного имени (O=домен, C=локальный) и установите период допустимости на 20 лет, затем нажмите Next

Рисунок 6
Примите рекомендации по умолчанию для базы данных сертификата и регистрирующих файлов (или поменяйте их, по желанию) и нажмите Next

Рисунок 7
Так как это отключенный корневой CA, то нет необходимости устанавливать IIS (Внутренний информационный сервис) и по этой причине выводится окно сообщения. Нажмите OK

Рисунок 8
Нажмите Finish

Рисунок 9
Нажмите Start / Programs / Administrative Tools / Certificate Authority
Откройте подокно вашего сервера центра сертификации и правой кнопкой мыши щелкните на Revoked Certificates. Нажмите All tasks / Publish

Рисунок 10
Выберите New CRL и нажмите OK
Скопируйте %windir%\system32\certsrv\certenroll\*.crt и *.crl в USB ключ. Вам понадобятся эти файлы для следующего подчиненного(subordinate) CA, который будет установлен
Вам также потребуется скопировать эти файлы в расположение CDP HTTP, как показано в представленном ранее файле caconfig.inf
Сделайте необходимые замены параметра в ниже приведенном файле (выделены красным цветом) и запустите файл с командной строки

Рисунок 11
Вы установили корневой CA.

Мы говорили, что есть причины безопасности, по которым необходимо держать корневой CA и политику CA (root and policy CA) отключенными. Только «выпускающие» CA рекомендуется держать включенными. Так как root and policy CA отключены, они не будут являться элементами домена. Если устройство, являющееся элементом домена, не зарегистрировано в домене в течение 6 месяцев (значение по умолчанию), тогда аккаунт устройства «зависнет» и больше не будет допущен к регистрации в домене.

Установка включенного «выпускающего» корпоративного CA

Чтобы установить включенный «выпускающий» CA, вам нужно выполнить следующие операции:

Подготовить файл CAPolicy.inf
Установить IIS (Internet Information Services)
Установить Windows Certificate Services
Подтвердите запрос sub-CA сертификата к родительскому CA
Установить sub-CA сертификат в корпоративный подчиненный CA
Запустить постконфигурационный скрипт
Опубликовать список CRL

Вот как вы можете сделать это:

Установить сервер с Windows Server 2003 Standard Edition, включая SP1 или более свежие версии и убедиться, что он является элементом домена
Убедитесь, что IIS (internet Information Services) установлены. Однако, если вы действительно хотите сделать это правильно, тогда пропустите часть IIS. Единственным предостережением является то, что вам определенно нужно знать ваш PKI прежде, чем вы пропустите компонент IIS. Преимуществом является более простая установка и на один вектор атаки меньше.
Сделайте необходимые замены параметров в файле CAPOlicy.inf, приведенном ниже (выделены красным цветом)

Рисунок 12: Имя файла: CAPolicy.inf
Скопируйте файл CAPolicy.INF в %windir%\capolicy.inf
Пройдите по Start Menu / Control Panel / Add or Remove Programs / нажмите Add/Remove Windows Components
В Windows Components Wizard, Выберите Certificates Services и нажмите Next

Рисунок 13
Обратите внимание на окно сообщений. Вы не должны переименовывать компьютер, раз установлены сервисы сертификата Windows. Нажмите Yes
В поле типа центра сертификации, нажмите на Enterprise subordinate CA и поставьте «галочку» напротив “Use custom settings to generate the key pair and CA certificate” и нажмите Next

Рисунок 14
Выберите CSP, который вы хотите использовать для вашего «выпускающего» CA. Для простоты мы выбрали Microsoft Strong Cryptographic Provider v1.0, однако, вы также можете выбрать другой CSP, если вы, например, установили Hardware Security Module (HSM) и соединились с сервером через HSM, прежде чем вы начали процедуру установки CA.
Выберите по умолчанию хешированный алгоритм SHA-1

Установите длину ключа 2048

Убедитесь, что опции “Allow this CSP to interact with the desktop” и “Use an existing key” не выбраны. Нажмите Next

Рисунок 15
Введите полное имя для вашего «выпускающего» CA и установите период доступности (Validity period) на 5 лет, затем нажмите Next

Рисунок 16
Примите рекомендации по умолчанию для базы данных сертификата и регистрирующих файлов (или поменяйте их, по желанию) и нажмите Next
Отображено окно запроса сертификата СА. Выберите Save the request to a file и введите путь и имя файла (модуль оперативной помощи автоматически добавит .req расширение в имя файла). Скопируйте файл в USB ключ для дальнейшего использования. Нажмите Next. Мы будем использовать этот запрос файла потом в нашем кратком руководстве

Рисунок 17
Будут добавлены некоторые компоненты прикладной программы сертификата IIS. Нажмите Yes

Рисунок 18
(Дополнительно) Если вы не включили ASP поддержку в IIS, то появится следующее окно сообщений. Нажмите Yes

Рисунок 19
Вы еще не все выполнили. Как показано в окне сообщений – вам нужно создать личный ключ для вашего нового «выпускающего» центра сертификации.

Рисунок 20

Нажмите OK для продолжения.
Нажмите Finish

Рисунок 21
Прежде, чем вы продолжите, вам нужно опубликовать сертификат и список отмен для вашего корневого CA в Active Directory. Это легко делается следующим образом:
a) Скопируйте созданные во время установки корневого CA файлы *.crt и *.crl в папку %systemroot%\system32\certsrv\certenroll в сервере «выпускающего» CA.

b) Запустите ниже приведенный скрипт из командной строки в той же папке вашего «выпускающего» CA. Вы должны запустить скрипт как пользователь, являющийся членом группы Cert Publishers в Active Directory (кто-либо с правами админа домена).

Рисунок 22

Скрипт автоматически обработает полное имя файла и выполнит необходимые команды.
Убедитесь, что у вас есть сертификат запрашиваемого файла, созданного в Шаге 12. Зарегистрируйтесь на сервере корневого CA.
Из корневого CA сервера нажмите Start / Programs / Administrative Tools / Certificate Authority
Откройте панель вашего CA сервера и правой кнопкой мыши щелкните на имени сервера. Нажмите All tasks / Submit new request…

Рисунок 23
Сохраните запрашиваемый файл, созданный в Шаге 12 и нажмите OK
В левой панели нажмите Pending Requests. Расположите запрос сертификата в правой панели / Правой кнопкой мыши щелкните на запросе сертификата и выберите All Tasks / Issue
Дальше нам нужно экспортировать сертификат. В левой панели нажмите Issued Certificates. В правой панели щелкните правой кнопкой мыши на сертификате и нажмите Open

Рисунок 24
Нажмите на ярлык details и щелкните на Copy to file…

Рисунок 25
Показан Certificate Export Wizard. Нажмите Next

Рисунок 26
Выберите ”Cryptografic Message Syntax Standard ….” и ”Include all certificates in the certification path if possible”. Нажмите Next

Рисунок 27
Сохраните сертификат в тот USB ключ, используемый в Шаге 12. Нажмите Next

Рисунок 28
Нажмите Finish, а затем OK
Теперь вы возвратитесь к «выпускающему» CA и нажмите Start / Programs / Administrative Tools / Certificate Authority
Откройте панель сервера CA и правой кнопкой мыши щелкните на имени сервера. Нажмите All tasks / Install CA certificate

Рисунок 29
Сохраните сертификат, который вы выпустили в Шаге 27 и нажмите OK
Откройте панель вашего сервера CA и правой кнопкой мыши щелкните на имени сервера. Нажмите Start service

Рисунок 30
Скопируйте %windir%\system32\certsrv\certenroll\*.crt и *.crl в USB ключ. Вам нужно будет скопировать эти файлы в ваши Веб-серверы, используемые, как Certificate Distribution Points (CDP), которые используют HTTP протокол. Это HTTP, базирующийся на CDP URL, который вы ранее определили в caconfig.inf «выпускающего» CA.
Примечание: Эта задача будет распланирована и автоматически запущена.
Сделайте необходимые замены параметров в ниже приведенном файле (выделены красным цветом) и запустите файл через командную строку.

Рисунок 31
Откройте панель вашего сервера CA и правой кнопкой мыши щелкните на Revoked Certificates. Нажмите All tasks / Publish

Рисунок 32
Выберите New CRL и нажмите OK
И, наконец, вы завершили установку.

Панель инструментов

Одна из вещей, которая будет иметь важное значение для вас и вашей PKI – это панель инструментов, которая содержит правильные инструменты. Она поможет вам поддерживать вашу PKI в стабильном состоянии и решать некоторые проблемы быстро и безболезненно. Однако, это непростая задача, т.к. существует очень много инструментов, поэтому мы должны выбрать самые лучшие из них. Ниже приведены параметры вашей панели инструментов Microsoft PKI (не в обязательном порядке):

Certificate Services или службы сертификатов (certsrv.msc) – Эта MMC содержит основные функции, необходимые для настройки и поддержки вашей PKI.
Certificate Templates или шаблоны сертификатов (certtmpl.msc) – Эта MMC используется для поддержки и обеспечения безопасности шаблонов сертификатов.
Certificate Manager или менеджер сертификатов (certmgr.msc) – Эта MMC используется для контроля сертификатов, которые установлены на компьютере или используются определенным пользователем.
Certutil.exe – это утилита, работающая из командной строки, которая делает то же самое, что консоль Certificate Services MMC, плюс многое другое.
Event Viewer или просмотр событий (Eventvwr.msc) –Консоль Event Viewer MMC нетипичная. Этот инструмент очень важен при устранении неисправностей с вашей PKI, в чем вы скоро убедитесь.
Инструменты корпоративной Enterprise PKI (PKIview.msc) – Консоль MMC для контроля состояния PKI, которая должна стать вашим лучшим новым другом.
Capimon.exe – позволяет администратору контролировать безопасность вызовов CryptoAPI и результатов.

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

Всегда начинать устранение неисправностей с проверки журналов событий (event log). Это может показаться очевидным, но практически все ошибки, связанные с PKI, заносятся в журналы событий (event log). Хотя вы и можете отображать сообщения об ошибках от различных программ, как Certificate Services MMC, журнал событий – это гораздо более простой способ для просмотра и устранения ошибок, связанных с PKI.
Используйте инструменты PKIview.msc для быстрого просмотра состояния вашей PKI. PKIview.msc обычно позволяет обнаружить некоторые из наиболее часто встречающихся ошибок, включая потерю или просрочку CRL или просроченный сертификат CA certificate. Если все выглядит нормально, то вы можете сконцентрироваться на проблемах, связанных с сертификатами, таких, как настройки безопасности для шаблонов сертификатов и т.п.
Если ошибка по-прежнему неочевидна, или же ее трудно устранить с помощью предыдущих этапов, то просмотрите информацию из списка ресурсов в конце этой статьи, или поищите решение в новостях или на форуме на сайте support.microsoft.com

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

Что с доступностью вашей PKI и ваших корневых сертификатов (root certificate)?
Доступен ли CRL?
Правильно ли работают выпущенные сертификаты?
Правильно ли работают компоненты инфраструктуры или приложения, которые используют сертификаты вашей PKI?
Что с производительностью систем, которые используют сертификаты вашей PKI?
Появлялись ли какие-нибудь сообщения об ошибках, связанные с сертификатами, установленными на компьютере?

Давайте продолжим и посмотрим на несколько утилит из набора инструментов, а также, как они могут облегчить нам жизнь по отношению к PKI.

Консоли Certificate Services и Certificates Templates MMC

Консоль Certificate Services MMC (службы сертификатов или certsrv.msc) – это ваша основная консоль для администрирования PKI. Вы должны потратить немного времени и познакомиться с этой консолью лучше, так как с ее помощью можно глубже заглянуть в мир Microsoft PKI. С помощью этой консоли вы можете лучше понять, что такое AIA, CDP, шаблоны сертификатов V2 certificate templates, и т.п., как они связаны с областями, о которых мы рассказывали в предыдущих статьях. Встроенная помощь может также существенно помочь, т.к. она содержит небольшой раздел с рекомендациями (как и многие другие встроенные файлы помощи в операционной системе Windows Server 2003). Большинство проблем с Microsoft PKI чаще всего связано с проблемой прав, при выпуске сертификата, или с доступностью CRL. Поэтому давайте посмотрим на пару примеров, где этот инструмент может быть очень полезен для устранения проблем с вашей PKI.

Одна из наиболее частых ошибок, связанных с PKI – это устаревший или недоступный CRL. Самый быстрый способ ее решения – это опубликовать CRL с помощью консоли Certificate Services MMC, но это можно также выполнить из командной строки, о чем вы очень скоро узнаете.

Рисунок 1: Публикация CRL

Это должно войти у вас в привычку проверять, выпущен сертификат или нет, проверяя в подменю “Failed Requests (невыполненные запросы)” в левой части консоли MMC console. Из этого меню вы сможете выяснить, почему возникла ошибка при попытке выпустить сертификат. Очень часть эту ошибку очень сложно прочитать в разделе “Failed Request (невыполненные запросы)”. Но эта же самая ошибка будет записана в прикладной журнал (application log). И поэтому проще скопировать запись из журнала событий (event log) из Event Viewer (просмотр событий), чем просмотреть в консоли Certificate Services MMC, то это будет более предпочтительным способом проверить наличие ошибок, связанный с PKI, если конечно, вы не используете некий способ для передачи администрирования и настройки вашей консоли.

Еще одна частая ошибка – это неправильные настройки безопасности для шаблонов сертификатов (certificate template). Вы можете изменить безопасность для шаблонов сертификатов с помощью консоли Certificate Services MMC, либо щелкнув правой кнопкой мыши на Certificate Templates (шаблоны сертификатов) и выбрав пункт Manage (управление) или запустить новую консоль MMC, в которую вы добавите шаблоны сертификатов Certificate Templates (certtmpl.msc). В любом случае в консоли Certificate Templates MMC, вы должны выбрать свойства для шаблона сертификата, который вы хотите использовать. Затем перейдите на закладку Security (безопасность) и убедитесь, что правильной группе безопасности (security group) разрешено получать сертификаты, задав для этой групп права на чтение “Read” и на внесение в список “Enroll”.

Рисунок 2: Проверьте правильность настроек безопасности для шаблонов сертификатов

PKIview.msc

Один из самых важных инструментов для устранение неполадок с Microsoft PKI - это PKIview.msc, который можно найти в Windows Server 2003 Resource Kit. С помощью этого инструмента, вы можете проверить статус вашей PKI. Если вы запустите графический инструмент, то вы увидите различные индикаторы, которые позволят вам оценить состояние вашей PKI. Зеленые отметки сообщают, что все в порядке с вашей PKI. Однако, желтый знак предупреждения, говорит о том, что сертификат или список вызовов сертификатов Certificate Revocation List (CRL) закрыт по истечении срока. Если вы видите красные ошибки, то это означает, что CRL или Authority Information Access (AIA) недоступны. Красные ошибки могут также говорить о том, что CA нельзя доверять. Если это так, что щелкните правой кнопкой мыши на ошибке и выберите “Copy URL”. Вставьте URL в веб браузер, и если этот адрес на доступность, или используйте инструмент под названием adsiedit.msc из средств поддержки Windows Support Tools для проверки, что опубликованный CDP содержит список вызовов или доверия.

Этот инструмент способен на гораздо больше, и вы должны запускать его, как минимум, один раз в неделю для проверки состояния вашей PKI. Описание ошибки позволит быстро определить, где именно возникла ошибка, но это не предоставить вам окончательного решения. Вам по-прежнему необходимо будет выполнить некую детективную работу, используя другие инструменты и списка в этой статьи, или поискать с помощью Google.

Рисунок 3: PKIview.msc – великолепный инструмент для отладки

{mosimageCertutil.exe}

Certutil.exe

Но самым главным инструментом для Microsoft PKI без сомнения является Certutil.exe. Эта мощная утилита, работающая из командной строки заменяет набор инструментов в Windows 2000 под названием Dsstore.exe. Есть несколько преимуществ использования Certutil.exe. Во-первых, его легко использовать в сценариях, и он способен на гораздо больше по отношению к настройке, документации и устранению неисправностей, по сравнению с другими инструментами из набора инструментов, входящих в состав PKI toolbox. Еще одно преимущество, которое очень часто упоминается, заключается в том, что он позволяет запустить много инструментов для сбора данных для обычного пользователя. Это особенно хорошо для устранения проблем с сертификатами, не нарушая безопасности вашей PKI. Причина, по которой устранение проблем у вашей PKI с помощью Certutil.exe не нарушает безопасность вашей PKI, заключается в том, что многие из основных параметров настройки не доступны до тех пор, пока вы не раздадите необходимые права.

Еще одним преимуществом Certutil.exe является встроенная возможность изменения управления. Многие настройки служб сертификатов (Certificates Services) хранятся в реестре Windows в разделе:

“My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc”

Если вы произвели какие-нибудь изменения в вашей PKI с помощью параметра “certutil –setreg” то утилита отобразит сперва старое значение параметра, а затем его новое значение.

Мы не будем рассматривать все различные возможности и параметры Certutil.exe, т.к. их слишком много. Однако, вы можете ввести команду “Certutil -?”, чтобы узнать обо всех параметрах. Есть также возможность переноса версии Certutil.exe для операционной системы Windows Server 2003 на операционную систему Windows Vista, Windows XP и Windows 2000. Все, что вам необходимо сделать – это просто скопировать файлы Certutil.exe, Certcli.dll и Certadm.dll в папку на вашем компьютере с операционной системой Windows Vista, XP или Windows 2000. Не нужно регистрировать никаких файлов DLL и т.п. Просто запустите утилиту в командной строке из этой папки.

Заключение

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

Внешние ресурсы

Эта статья была написана при помощи огромного количества ресурсов. Все самые лучшие статьи, посвященные Microsoft PKI, были собраны в одном месте, которое вы можете найти на веб портале Microsoft PKI Web Portal http://www.microsoft.com/pki

Хотите увидеть, как компания Microsoft делает PKI, то посмотрите IT Showcase -Deploying PKI Inside Microsoft http://www.microsoft.com/technet/itsolutions/msit/security/deppkiin.mspx

форум администрирование windows