Размещение данного переведенного материала на других сайтах без разрешения компании запрещается
| Вид материала | Руководство |
- Маркетинговый план 6 Производственный план 11 Источники финансирования проекта 12 График, 137.08kb.
- Экономическая информатика, 375.46kb.
- Инструкция по мерам пожарной безопасности в помещениях пожарной части Впомещениях пожарной, 14.39kb.
- В. Н. Иванов тайны гибели цивилизаций минск литература, 5460.54kb.
- Юнгианская психология, 3499.92kb.
- Морфологиясе, 15844.68kb.
- Роль зрительного опыта в развитии психических функций, 7467.96kb.
- Специальное предложение для спонсоров, 46.81kb.
- У наргис, 640.65kb.
- Хайнц Кохут Анализ самости системный подход к лечению нарциссических нарушений личности, 5101.91kb.
1 2
| Краткое руководство по Microsoft PKI (Часть 1) |
|
Эта статья переведена силами и средствами компании ссылка скрыта. Размещение данного переведенного материала на других сайтах без разрешения компании ссылка скрыта запрещается.
 |
| Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте: В этой статье, состоящей из трех частей, я кратко расскажу вам, как устанавливать, проектировать и отлаживать 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). Как вы можете заметить, сертификаты сегодня повсюду, и часто их используют, даже не беспокоясь об их существовании. Некоторые наиболее часто встречающиеся сценарии, когда используются сертификаты (по порядку):
Как вы видите, сертификаты используются во многих местах, и их основное назначение для усиления безопасности вашей инфраструктуры и решений 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 Брайен Комар (Brian Komar), который является автором превосходной книги "Microsoft Windows Server 2003 PKI and Certificate Security" (смотрите ссылку в конце статьи) и который написал несколько статей для Microsoft и давал лекции по различным субъектам Microsoft PKI, часто говорит, что: "PKI усиливает политики безопасности в вашей организации". Это утверждение, на мой взгляд, очень хорошо все выражает. Убедитесь, что в вашей компании существует политика безопасности (security policy), которая направлена на бизнес и стратегию IT. Затем необходимо подготовить эту стратегию для приложений и служб безопасности, которые будут зависеть от сертификатов (certificates). Т.к. политики безопасности необходимо согласовать с управляющими или даже с главами (в конце концов, эти люди отвечают за бизнес стратегию вашей компании), то у вас зажжется зеленый цвет, и вы можете приступить к вашей реализации PKI. Если вы достаточно несчастливы, и в вашей компании нет корпоративной политики безопасности (security policy), то вы можете прейти по следующей ссылке и посмотреть примеры различных политик безопасности, включая примеры политик безопасности, которые работают по стандарту ISO 17799 standard. The SANS Security Policy Project ссылка скрыта ссылка скрыта Создание одной или нескольких политик для сертификатов (Certificate Policies) Я согласен. Политике это не самая волнительная вещь в мире, но кроме всего прочего, они по-прежнему очень важны. И если вы хотите избежать всех проблем с вашей инфраструктурой PKI, то лучше правильно создать политику для сертификата Certificate Policy (CP). Политика для сертификата (certificate policy) описывает, как и кто выпускает и распределяет сертификаты для субъектов (т.е. субъектами могут быть пользователи, компьютеры, устройства и т.д.). Это может быть очень сложная задача, хотя и очень важная, но не волнуйтесь. Просто выполните шаги, представленные ниже, и вы будете на правильном пути к созданию политики сертификата для вашей PKI.
Создание предложения для сертификата Мы почти закончили с этапом планирования, но нам все еще нужно создать предложение Certificate Practice Statement (CPS). Это предложение CPS очень похоже на политику для сертификата Certificate Policy, за исключением того, что она фокусируется на безопасности полномочий сертификатов Certificate Authority (CA) во время операций и управления сертификатами, выпущенных CA. CPS обычно гораздо короче, чем политика безопасности Security Policy и содержит информацию относительно того, кто отвечает в случае, если сертификат не может адекватно защитить то, что он должен защищать. Примером может служить безопасное соединение SSL/TLS, если пользователь вводит номер своей кредитной карты. Другие области (как минимум), которые должны быть включены в CPS – это как обрабатывается проверка, обновление и аннулирование CA, ответственным за выпуск сертификатов. Вы можете рассматривать CPS, как соглашение между пользователем сертификата и компанией, которая отвечает за выпуск CA. И как вы уже могли догадаться, у нас есть несколько великолепных примеров для CPS, которая может показаться вам знакомой.
В отличие от политики сертификатов Certificate Policy, CPS необходимо всегда делать общедоступной, чтобы пользователь сертификата всегда имел доступ к CPS. В каждом сертификате, выпущенном вашей CA должны быть ссылка, которая указывает место, где опубликовано CPS. Более подробно мы рассмотрим это в следующих двух статьях. Заключительное слово Мы предоставили вам краткий обзор некоторых самых важных проблем, на которые стоит обратить внимание в время фазы планирования построения Microsoft PKI, однако, очень важно, чтобы вы посмотрели на информацию, приведенную в этой статье с критической точки зрения, если вы хотите построить PKI в высоко безопасной среде. Помните, что эта серия статей служит лишь кратким руководством, чтобы помочь вам понять великолепие Microsoft PKI в очень короткий срок. Если вы хотите узнать все детали и тонкости планирования, дизайна и установки, то вы должны взглянуть на ссылки на ресурсы, приведенные ниже. В следующей статье мы более подробно рассмотрим различные настройки для дизайна и установки, основываясь на лучших рекомендациях. Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте: | |||
| Краткое руководство по Microsoft PKI -Часть 2: Проектирование |
| ||
Эта статья переведена силами и средствами компании ссылка скрыта. Размещение данного переведенного материала на других сайтах без разрешения компании ссылка скрыта запрещается.
| |
| Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте: Это наша вторая статья из цикла, посвященного Microsoft PKI. В нашей первой статье мы кратко рассмотрели, как подготовить и как планировать наш Microsoft PKI. В этой статье мы будем немного более техничными. Мы рассмотрим некоторые проблемы при проектировании PKI. В этой статье мы покажем вам, как избежать общих ошибок на фазе проектирования. Проектирование PKI Когда вы проектируете ваш PKI, то необходимо учитывать следующие вещи:
Давайте поближе посмотрим на каждую из этих проектных проблем. Проектирование иерархии CA, которая хорошо масштабируется Количество и уровни CA вы должны учитывать сразу, в зависимости от ваших требований к безопасности и доступности. Вы должны постараться организовать вашу иерархию в соответствии с вашими нуждами. В действительности не существует каких- либо рекомендаций относительно того, сколько уровней CA вам нужно, хотя очень редко кому-либо необходимо 4 или более уровней. Однако, существует правило большого пальца, которое мы представили в таблице 1 ниже, которое здорово поможет вам идти в верном направлении:
Как дополнительное примечание, вы можете вспомнить из предыдущей статьи, что существует нечто, называемое политикой сертификата (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 ниже представлены рекомендуемые размеры ключей:
Обычно, целях безопасности рекомендуется использовать ключ размером 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, убедившись, что все CA, за исключением выпускающего CA, работают в автономном режиме (offline). Под этим мы понимаем, что они должны быть вне сети и подключаться к сети лишь тогда, когда для CRL и выпущенным сертификатам для всех CAs во всем PKI необходимо обновление. Обычно, корневой и стратегический CA выключаются полностью, но опять же это зависит от того, насколько хороша у вас физическая безопасность, и как защищаются закрытые ключи CA private keys, а также насколько надежно ваше аппаратное обеспечение. Где создавать точки публикации Последняя область, на которую мы обратим внимание перед тем, как начнем реализацию PKI, это размещение публикации для списков Certificate Revocation Lists (CRL) и общих ключей (public key) CA. Их также называют точки размещения сертификатов (Certificate Distribution Points или CDP). Существуют различные протоколы, которые можно использовать для описания CDP. Это:
Ниже на рисунке 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, который состоит из комбинации автономных, отдельно стоящих CA и корпоративных выпускающих CA. Мы настоятельно рекомендуем вам изучить таблицы, представленные в этой статье, т.к. в них содержатся очень полезные советы, которых мы лишь кратко коснулись. В нашей следующей статье, посвященной PKI, мы будем использовать рекомендации, представленные в этой статье, а также покажем вам, как устанавливать PKI с помощью поэтапного метода. Внешние ресурсы Для написания этой статьи использовалось много великолепных ресурсов. Все замечательные статьи по Microsoft PKI собраны в одном месте, вы можете найти их на веб портале Microsoft PKI Web Portal ссылка скрыта Хотите увидеть, как Microsoft делает PKI, то проверьте IT Showcase -Deploying PKI Inside Microsoft ссылка скрыта Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте: | ||||||||||||||||||||||||||||||||||||||||
| Краткое руководство по Microsoft PKI – Часть 3: Установка |
| | ||||||||||||||||||||||||||||||||||||||
Эта статья переведена силами и средствами компании ссылка скрыта. Размещение данного переведенного материала на других сайтах без разрешения компании ссылка скрыта запрещается.
| |
| Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте: Теперь мы переходим к третьей части из четырех по краткому руководству к Microsoft PKI. В первой части мы быстро просмотрели, как подготовить и распланировать ваш Microsoft PKI. Во второй части мы углубились в оформление и на практике посмотрели некоторые установки. В этой части мы больше времени уделим методике и покажем вам, как установить PKI основанную на сервисах сертификата Микрософт в Windows Server 2003. Установка PKI Основываясь на некоторых знаниях об оформлении, полученных из предыдущих частей, пришло время начать установку вашего PKI. Так как это краткое руководство, мы рассмотрим сразу несколько вещей, потому что они принадлежат к оформлению. Также мы покажем вам, как установить 2-х уровневую иерархию, состоящую из отключенного корневого Certificate Authority (CA) и включенного «выпускающего» CA в том же PKI, использующем наилучшие практические методы. Однако прежде, чем мы начнем установку, давайте объясним кое-что на практике. На Рисунке 1 мы проиллюстрировали наилучшее применение периода допустимости для каждого CA на каждом уровне (базирующегося на 3-х уровневой иерархии для полного обзора). Преимуществом этой модели является то, что она будет всегда гарантировать вам совместимость «выпускаемых» сертификатов на каждом уровне. Если вы только хотите использовать 2- уровневую иерархию, просто переместите CA на уровень 3. Модель все еще будет использовать.  Рисунок 1: Наилучшее применение периода допустимости для каждого CA на каждом уровне Еще вам следует подготовить текстовый файл CAPolicy.inf прежде, чем мы начнем установку. Этот файл используется для управления вашими настройками сервиса сертификатов Windows. В этом файле, вы найдете такие важные вещи, как:
Создайте файл, используя Notepad и сохраните его в %windir%\capolicy.inf (например, C:\Windows\capolicy.inf). Мы упростили для вас задачу, поставив файлы в ниже приведенном пошаговом руководстве. Запомнив эту информацию, настало время приступить к практике. Установка отключенного корневого CA Чтобы установить отключенный корневой CA, вам нужно выполнить следующие операции:
Вот как вы можете сделать это:
 Рисунок 2: Имя файла: CAPolicy.inf
 Рисунок 3
Примечание: Это нормально, что опции Enterprise root CA и Enterprise subordinate CA не могут быть выбраны, так как этот сервер не является элементом домена.  Рисунок 4
Выберите по умолчанию хешированный алгоритм SHA-1 Установите длину ключа 4096 Убедитесь, что обе опции “Allow this CSP to interact with the desktop” и“Use an existing key” не выбраны. Нажмите Next  Рисунок 5
 Рисунок 6
 Рисунок 7
 Рисунок 8
 Рисунок 9
 Рисунок 10
|
- Вы установили корневой 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.
Примечание: Эта задача будет распланирована и автоматически запущена.
- Сделайте необходимые замены параметров в ниже приведенном файле (выделены красным цветом) и запустите файл через командную строку.
- Откройте панель вашего сервера CA и правой кнопкой мыши щелкните на Revoked Certificates. Нажмите All tasks / Publish
Рисунок 32 - Выберите New CRL и нажмите OK
- И, наконец, вы завершили установку.
Заключение
В этой статье, мы дали вам краткое руководство и практический совет, как лучше реализовывать PKI, состоящий из комбинации обоих отключенных автономных CA и кооперативного включенного «выпускающего» CA. Вам нужно знать, что скрипт используется дл публикации сертификата «коренного» CA и CRL файла в локальном запоминающем устройстве «выпускающего» CA, и Active Directory нуждается в модификации, если вы используете 3-х уровневую иерархию. Так происходит, потому что курс действий CA также нуждается в публикации в запоминающем устройстве локального сертификата нашего корпоративного «выпускающего» CA и также нуждается в публикации в Active Directory.
В некоторых местах вы можете найти третью часть статьи немного громоздкой, особенно в объяснении реализации включенного «выпускающего» CA. Но, однажды попробовав, вы обнаружите, что не так уж и трудно использовать полностью перегоревший PKI, который полностью расширяется и охраняется. В нашей последней статье в этой серии краткого руководства для PKI, мы покажем вам, как проверять нашу установку, так же как поддерживать и находить с последующим устранением PKI, используя несколько простых операций.
Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте: