Построение трехуровневой иерархической системы сертификатов PKI

Инфраструктура центра сертификации — своими руками

Цифровые сертификаты представляют собой эффективное средство определения подлинности, которое можно применять при аутентификации пользователей в процессе регистрации, для обеспечения безопасного обмена информацией в Internet и определения происхождения программного обеспечения. Одной из главных областей применения цифровых сертификатов является шифрование данных и электронная подпись сообщений электронной почты. С помощью последней получатели письма могут удостовериться, что письмо было послано именно данным отправителем и не изменено. Разобравшись с технологией цифровых сертификатов, можно научиться определять оптимальный тип иерархии центров сертификации CA (Certificate Authority) и какой вариант CA использовать — внешний или внутренний. Для тех, кто решит, что лучше использовать собственный CA, ниже приводится описание связанных с этим проблем, а также действий, которые следует предпринять для создания сервера сертификации, необходимого для выдачи собственных сертификатов. Начнем с краткого обзора частей инфраструктуры открытых ключей PKI (Public Key Infrastructure).

Структура PKI

Центр сертификации, или удостоверяющий центр, представляет собой сервер, который выдает цифровые сертификаты. CA проверяет легитимность частных лиц и организаций и выдает цифровые сертификаты, удостоверяющие их. Сервер CA, или сервер сертификатов, представляет собой компьютер, который выдает сертификаты. В данной статье термин CA будет часто использоваться для обозначения серверов выдачи сертификатов. Список отозванных сертификатов Certificate Revocation List (CRL) — это список сертификатов, которым больше нельзя доверять, обычно из-за того, что секретный ключ утерян, поврежден или скомпрометирован. Организации CA поддерживают серверы распространения списков CRL, CRL Distribution Point (CDP), на которых хранятся CRL. Доступ к размещенному в CA серверу CDP может осуществляться через общий каталог на сервере, по протоколам LDAP (Lightweight Directory Access Protocol), FTP или HTTP.

Каждая система, использующая технологию сертификации, должна иметь хранилище сертификатов, которое представляет собой базу данных, где хранятся цифровые сертификаты. Когда прикладная программа, использующая технологии сертификации, пытается воспользоваться сертификатом или проверить его, она в первую очередь обращается к хранилищу сертификатов. В системах Windows для просмотра содержимого хранилища сертификатов достаточно запустить Internet Explorer и выбрать Tools, Internet Options и перейти на вкладку Content. В версиях Windows начиная с Windows 2000 можно запустить консоль управления Microsoft Management Console (MMC) и воспользоваться оснасткой Certificates для обращения к хранилищу сертификатов.

Обычно серверы CA организовываются в двух- или трехзвенную иерархическую структуру и выполняют функции корневого, промежуточного и выдающего сертификаты серверов. Более подробно о том, почему трехзвенная иерархическая система, как правило, является оптимальным вариантом, рассказано во врезке «Использование трехуровневой структуры центра сертификации». На верхнем уровне иерархии располагается корневой CA, на втором уровне — один или несколько промежуточных CA, называемых иногда подчиненными CA. Под каждым из промежуточных СА располагаются один или несколько раздающих сертификаты CA. Предполагается, что вы задали явное отношение доверия корневому CA, корневой CA подтверждает достоверность промежуточных CA, которые, в свою очередь, подтверждают полномочия CA самого нижнего уровня. Выдающие сертификаты CA подтверждают достоверность сертификатов индивидуальных пользователей, которым были выданы сертификаты. На каждом уровне выдается сертификат для нижестоящего уровня и определяются политики и правила, управляющие использованием и временем жизни сертификатов. Иерархическая система взаимосвязей сертификатов формирует цепочку сертификации.

Чтобы лучше понять концепцию цепочки сертификации и связь этого понятия с процессом выдачи сертификата, обратимся к аналогии выдачи водительской лицензии, схематично представленной на рис. 1. На верхнем уровне иерархии помещены государственные (федеральные) органы — корневые CA (root CA), которые объединяют все штаты и обеспечивают проверку того, что водительская лицензия (цифровой сертификат), выданная одним штатом, будет соответственно воспринята в других штатах. На следующем уровне расположены штаты (промежуточные CA), которые решают, какие организации могут выдавать водительскую лицензию, и определяют сроки полномочий этих организаций. Эти организации (промежуточные или выдающие CA) определяют правила выдачи лицензий (где выдается лицензия, какие документы необходимо предъявить для ее получения, насколько часто требуется обновлять лицензию. Мы доверяем водительской лицензии потому, что доверяем выдавшей ее организации, организации доверяем потому, что доверяем штату, а штату доверяем потому, что доверяем стране. Примерно такая же схема работает и для сертификатов.

Рисунок 1. Цепочка сертификатов

Для начала необходимо назначить первый CA для цепочек доверия, для чего выбирается корневой CA. Сертификация корневого CA осуществляется им самим. Поскольку нет объекта с более высокими полномочиями, CA выдает себе сертификат с собственной подписью. Для систем, которые должны доверять корневому CA, выпускается сертификат корневого CA, содержащий открытый ключ (public key). Сертификат корневого CA размещается в контейнере Trusted Root хранилища сертификатов системы. Эту операцию необходимо выполнить для каждого сервера и рабочей станции, которые будут использовать сертификаты; цепочка сертификации приводит к данному корневому CA. Каждый сертификат, выданный корневым CA (т. е. промежуточный сертификат), содержит подпись, сгенерированную с помощью закрытого ключа (private key), аналогично тому, как водительская лицензия заверяется печатью выдавшей организации и подписью официально уполномоченного лица, что придает водительской лицензии статус официального документа. Точно так же каждый сертификат, выпущенный промежуточным CA, содержит подпись, позволяющую идентифицировать этот промежуточный CA. Для завершения цепочки сертификации конечный сертификат каждого отправителя содержит подпись промежуточного CA, выдавшего сертификат. Это позволяет проверить подлинность сертификата отправителя и таким образом удостовериться, что это тот самый отправитель (если только ни конечный, ни промежуточный сертификаты не скомпрометированы, не занесены в CRL и цепь сертификации не разорвана).

Вопросы реализации

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

Следует также определить, будете ли вы использовать внешний или собственный корневой CA. Выбирая известный внешний корневой CA, такой как VeriSign или Thawte, вы избавитесь от необходимости задавать явное внешнее доверительное отношение с этим корневым CA, добавляя его сертификат в свое хранилище. Кроме того, не придется организовывать обмен корневыми сертификатами с другими участниками обмена документами. Это может оказаться весьма важным фактором, поскольку организация такого обмена — занятие достаточно трудоемкое, а сертификаты основных внешних сертификационных центров, как правило, есть везде. Как видно из табл. 1, использование внешнего корневого CA избавляет нас от необходимости поддерживать сервер CA, но лишает гибкости в вопросе выбора политики сертификации, особенно это касается срока действия сертификата. Следует также принять во внимание стоимость приобретения сертификата уровня центра CA. Хотя, как правило, цена такого сертификата меньше затрат на приобретение сервера, программного обеспечения и сопровождение сервера CA. Вне зависимости от выбранного типа инфраструктуры PKI, необходимо убедиться, что находящийся в вашем ведении CA высшего уровня работал в изолированном режиме, т. е. не был подключен ни к какой сети. Эта мера позволяет снизить риск компрометации сервера или закрытого ключа каким-нибудь хакером. Если решено использовать собственный корневой CA, я рекомендую, чтобы промежуточные CA высшего уровня работали изолированно из тех же соображений безопасности.

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

Далее требуется определить необходимую стойкость ключа шифрования для своих сертификатов. Чем больше длина ключа в битах, тем более стойким он считается и тем меньше вероятность, что он может быть вычислен с использованием математических методов. Обратной стороной медали в данном случае является длительное время, необходимое для создания или обновления сертификатов и расшифровки сообщений, зашифрованных асимметричным ключом. Обычно для корневого CA и промежуточных CA используются 4096-разрядные ключи, 2048-разрядные для выдающих CA и 1024-2048-разрядные ключи для пользовательских сертификатов.

Последний фактор, который следует здесь рассмотреть, относится к CDP. CDP является источником, из которого можно получить корневые сертификаты и CRL. Необходимо определить серверы в сети, на которых будут размещены CDP и используемые протоколы доступа. На практике часто на серверах выдающих CA размещаются также Web-серверы, обеспечивающие доступ к CDP по протоколу HTTP. Кроме того, HTTP используется для предоставления доступа внешним клиентам к CDP, поскольку этот протокол поддерживается везде и обычно беспрепятственно пропускается брандмауэрами. Но возможно и использование других протоколов. Например, можно организовать доступ к CDP по протоколу FTP или через разделяемый файловый ресурс либо, при наличии развернутой инфраструктуры AD, доступ к CDP может быть организован через LDAP.

Настройка иерархии CA

Далее мы будем подробно рассматривать вопросы использования служб сертификации Certificate Services Windows на примере трехуровневой иерархии CA. На рис. 2 представлена схема и информационные потоки, связанные с этим процессом. Прежде всего, необходимо установить три сервера, ROOTCA, SUBCA и ISSUING; установить на них как минимум Windows 2000 или более новую версию, Microsoft Internet Information Services (IIS) версии 5.0 или более новую версию и развернуть последние пакеты обновлений и критические обновления для системы безопасности. Сервер ISSUING будет работать в локальной сети. На нем будет установлен CDP для всех трех CA. ISSUING обрабатывает запросы на проверку сертификатов конечных пользователей, так что здесь следует применять аппаратное обеспечение сервера с возможностью масштабирования, соответствующей прогнозируемой потребности в подключениях. Компьютеры ROOTCA и SUBCA не будут подключены к сети, так что они не требовательны с точки зрения возможности масштабирования. Их задача — обрабатывать единичные запросы и периодически генерировать CRL. Это, конечно, не означает, что сюда можно поставить старые настольные компьютеры, выведенные из эксплуатации три года назад. Цепочка CA представляет собой важную часть иерархии, так что здесь необходимо применять надежные, проверенные решения и принять меры по резервному копированию этих серверов и поместить сертификаты CA в надежное место. Поскольку ISSUING выполняет функции всех трех серверов CA, настройку операционной системы и IIS необходимо выполнить раньше установки службы Certificate Services на других компьютерах CA.

Рисунок 2. Список и последовательность задач, выполнение которых необходимо при построении иерархии CA

Установка серверов CA

В первую очередь устанавливается сервер ROOTCA, затем SUBCA и, наконец, сервер ISSUING. В целом процесс практически одинаков для каждого из трех CA; в табл. 2 приведены отличия в установке этих серверов, которая была произведена для построения трехуровневой иерархии нашего примера. Для начала установки каждого из наших CA в приложении «Установка/удаление программ» в панели управления выберите закладку «Установка компонентов Windows». Выберите Certificate Services и нажмите Next. В диалоговом окне с предупреждением о том, что вы не можете изменить имя сервера или его членство в домене, следует нажать Yes. Далее предлагается установить уровень авторизации сертификата (Certification Authority Type). Выберите тип CA в соответствии со значениями, приведенными в табл 2. После выбора типа CA отметьте флажок Advanced options (Дополнительно), как показано на экране 1, и нажмите Next (Далее). Параметр Enterprise CA будет недоступен, если компьютер не является членом домена AD.

Экран 1. Выбор типа CA

Мастер Windows Components Wizard позволяет задать параметры пары открытый/закрытый ключ, а также выбрать провайдера службы шифрования Cryptographic Service Provider (CSP) и алгоритм, используемый для шифрования и формирования электронной подписи. Выбор различных поставщиков CSP и алгоритмов шифрования обеспечивает разные возможности, в том числе учет экспортных требований по криптостойкости ключей шифрования и поддержку внешних устройств, таких как смарт-карты для хранения ключей. Обычно, если у пользователя нет каких-то специфических требований, можно оставить значение по умолчанию (Microsoft Base Cryptographic Provider 1.0 и SHA-1). Далее мастер позволяет установить длину ключа в соответствии со значениями, приведенными в табл. 2, после чего следует нажать Next.

Экран 2. Указание информации о CA

На странице CA Identifying Information (Идентификация CA), изображенной на экране 2, указывается информация, которая должна быть включена в сертификат, а также информация, которую операторы CA смогут использовать для проверки полномочий при выдаче подтверждения или отказа в ответ на запрос на сертификацию. Наиболее важным на этой станице является параметр CA name. Имя должно быть уникальным, подсистема безопасности использует его для определения местоположения соответствующего родительского сертификата в цепочке сертификации. Другие поля позволяют идентифицировать организацию (эта информация может совпадать для всех CA). Последнее поле указывает срок действия данного корневого сертификата. Поскольку корневой CA сертифицирует сам себя, этот параметр доступен только через интерфейс ROOTCA. Продолжительность жизни сертификатов подчиненных и выдающих CA зависит от продолжительности действия родительского CA и управляется через системный реестр на серверах ROOTCA и SUBCA соответственно. Более подробно об этом будет рассказано ниже.

Для продолжения работы мастера нужно нажать Next. Процедура установки сформирует криптографический ключ и предложит указать местоположение для файлов базы данных, используемой службой сертификатов Certificate Service. Мастер позволяет разделить первичную (primary) базу данных и журнал базы транзакций. Я рекомендую, чтобы эти файлы были размещены на различных разделах. Помимо размещения файлов базы данных необходимо указать папку общего доступа для организации точки доступа к информации авторизации Authority Information Access (AIA) для получения сертификата CA. По умолчанию назначается папка C:CAConfig, но можно выбрать любую другую. Для упрощения сопровождения рекомендуется использовать одинаковые имена общих папок на всех трех серверах.

Специальная настройка корневого CA

После завершения работы мастера необходимо выполнить некоторые изменения на корневом CA, чтобы добиться соответствия эксплуатационным требованиям и обеспечить удобную работу для других CA и тех, кто будет использовать сертификаты. В первую очередь необходимо изменить параметры системного реестра, отвечающие за срок действия сертификатов, выдаваемых корневым CA подчиненным CA. Значение по умолчанию составляет 1 год, что слишком мало для практического применения. Для увеличения продолжительности жизни сертификатов нужно с помощью редактора системного реестра изменить значения параметров HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesCertSvcConfigurationValidityPeriod и HKEY_ LOCAL_MACHINESYSTEM CurrentControlSetServicesCertSvcConfigurationValidityPeriodUnits в соответствии со значениями, приведенными в табл. 2. Назначение и использование этих параметров рассматривается в статье Microsoft «HOW TO: Change the Expiration Date of Certificates That Are Issued by a Windows 2000 Certificate Authority (http://www.support.microsoft.com/?kbid=254632)». Редактор реестра для этой цели можно задействовать только на отдельном (не подключенном к локальной сети) компьютере. Параметр ValidityPeriod указывает единицу измерения срока действия сертификатов — дни, недели, месяцы или годы. Параметр ValidityPariodUnits содержит числа — 10, 20 и т. д. Таким образом, для корневого CA в нашем примере значение ValidityPeriod указывается years (годы), а ValidityPariodUnits имеет значение 10, определяя срок жизни промежуточных сертификатов, выданных этим CA, равным 10 годам.

Далее необходимо изменить настройки размещения CRL и корневых сертификатов (CDP и AIA). Перед тем как начать этот процесс, необходимо определить, как будет предоставляться доступ к CDP и AIA. Как правило, для доступа следует применять протокол HTTP, а в качестве вторичного протокола задействовать LDAP или FTP. Если по каким-то причинам невозможно предоставить доступ по второму протоколу, следует задать резервную точку доступа, например размещенные на отдельных компьютерах серверы WWW. В нашем примере на CA ISSUING используется IIS для обеспечения доступа по протоколу HTTP и AD для предоставления доступа по протоколу LDAP. Сервер ISSUING является единственным CA, который подключен к сети, так что он будет использоваться для предоставления доступа по протоколу HTTP к CDP и AIA от имени всех трех CA. Именно поэтому необходимо выполнить установку операционной системы для ISSUING до установки других CA. Хранение сертификата корневого CA в каталоге AD предоставляет еще одно преимущество: поскольку указывается, что данный сертификат представляет собой сертификат корневого CA, AD автоматически добавляет его в каждое хранилище сертификатов для каждого компьютера, работающего под управлением Windows сразу или после первой загрузки. Администратору не придется выполнять дополнительную работу по установке данного сертификата на компьютеры клиентов, если все они работают под Windows 2000 или более новой версией (на другие клиенты, к сожалению, сертификат корневого CA устанавливать придется). Если же администратор все-таки решит не устанавливать этот сертификат в AD (при установке корпоративного CA такой возможности просто не будет) или если будет очевидно, что данный сертификат следует установить только на ограниченное подмножество компьютеров, для распространения сертификата можно воспользоваться групповыми политиками. Подробные инструкции на эту тему содержатся в справочной системе, доступной после установки служб Certificate Services.

Для переопределения CDP и AIA необходимо выполнить следующие шаги:

1. На ROOTCA скопировать содержимое каталога C:winntsystem32 CertSrvCertEnroll на любой флэш-накопитель и скопировать эти файлы в общую папку ISSUINGCertEnroll.
2. В консоли управления MMC вызвать оснастку Internet Service Manager (ISM, Управление службами Internet), создать виртуальный каталог CDP на сайте по умолчанию для сервера ISSUING, причем этот виртуальный каталог должен указывать на папку CertEnroll (используйте явное указание папки C:winntsystem32 CertSrvCertEnroll). После создания виртуального каталога CDP следует запомнить связанный с ним адрес URL (например, http://ISSUING. hp.com/CDP), этот адрес потребуется для выполнения дальнейших настроек.
3. Зарегистрировавшись на сервере ISSUING с правами администратора домена (Domain Administrator), нужно вызвать командную строку и перейти в папку CertEnroll. Там должны содержаться файлы .crl и .crt, скопированные через флэш-накопитель с сервера ROOTCA. Эти файлы могут называться, например, HP Root CA.crl и HP Root CA.crt.
4. Воспользуйтесь утилитой Dsstore (входит в состав Microsoft Windows 2000 Server Resource Kit), чтобы разместить корневой сертификат и CRL в AD. Общий формат этой команды выглядит так: is Dsstore <-функция> <загружаемый файл> <имя CA> <сервер>. В нашем примере, если домен называется hp.com, команда будет выглядеть следующим образом:

   Dsstore DC=hp,DC=com -addcrl «HP Root CA.crl»
    «HP Root CA» ROOTCA
   
   
   Dsstore DC=hp,DC=com -addroot «HP Root CA.crt»
    «HP Root CA»

   Обратите внимание, что DC= должно быть написано заглавными буквами.
   
   Первая команда импортирует CRL, вторая импортирует в AD сертификат корневого CA. Каждая команда возвращает строку запроса LDAP, которую следует сохранить для определения CDR и AIA в качестве корня. Например, предыдущие вызовы Dsstore вернули следующие значения:

   LDAP:///CN=HP Root CA,CN=ROOTCA,CN=CDP,CN=Public
   
   
    Key Services,CN=Services,
   
   
   CN=Configuration,DC=HP,DC=COM?certificateRevocationList?
   
   
   base?objectclass=cRLDistribution Point
   
   
   LDAP:///CN=HP Root CA,CN=AIA,CN=Public Key 
   
   Services,CN=Services,CN=Configuration,
   
   
   DC=HP,DC=COM?cACertificate?base?
   
   
   objectclass=certificationAuthority

5. На ROOTCA нужно запустить оснастку MMC Certificate Authority, которая устанавливается при установке Certificate Services. Щелкните правой кнопкой мыши по корневому CA и выберите Properties. Перейдите на вкладку Policy Module, нажмите Configure и щелкните на вкладке X.509 Extensions.
6. В двух разделах, CDP и AIA, очистите имеющиеся значения.
7. Далее требуется настроить HTTP для разделов CDP и AIA. Нажмите Add и введите URL виртуального каталога CertConfig и за ним соответствующую подстановочную строку (значения см. в табл. 3). Служба Certificate Services будет использовать эти подстановочные строки для заполнения полей CDP и AIA в выданных сертификатах. Например, для CDP с доступом по протоколу HTTP надо ввести (без пробелов): HTTP://ISSUING.HP.COM/CDP/%CA_NAME%%CERT_SUFFIX%.crl, а для AIA, соответственно: HTTP://ISSUING.HP.COM/CDP/%SERVER_DNS_NAME%_%CA_NAME%%CERT_SUFFIX%.crt
8. Далее необходимо добавить значения, определяющие местоположение CDP и AIA для доступа по LDAP. Нажмите Add и введите запросы LDAP, полученные при вызове команды Dsstore. Для CDP это будет первый запрос (заканчивающийся на cRLDistributionPoint), соответственно, для AIA - второй (оканчивающийся на certificationAuthority).
9. Для активации сделанных изменений следует остановить и повторно запустить службу Certificate Services. После сделанных изменений можно начинать использовать корневой CA для создания сертификатов на промежуточных CA.

Специальная настройка промежуточных и выдающих CA

На начальном этапе настройки для промежуточного CA (SUBCA) и выдающего CA (ISSUING) действия совпадают с настройкой корневого CA. Первое отличие заключается в том, что при выборе типа CA указывается Stand-alone subordinate (отдельный подчиненный) и Enterprise subordinate (корпоративный подчиненный) соответственно. Поскольку промежуточный CA не будет подключен к локальной сети, добавление корневого сертификата в системное хранилище сертификатов необходимо будет выполнить вручную. Копию корневого сертификата можно скопировать через флэш-накопитель с одного из AIA (ISSINGCertEnroll или ROOTCA CertConfig). Откройте оснастку Certificates и выберите режим управления сертификатами для локального компьютера. Раскройте дерево контейнера так, чтобы можно было добраться до контейнера Certificates, вложенного в Trusted Root Certification Authorities. Щелкните правой кнопкой мыши на контейнере Certificates и выберите в контекстном меню All Tasks пункт Import. Выберите файл сертификата с дискеты, нажмите Open для вызова мастера Certificate Import Wizard и выполните импорт сертификата в хранилище доверительных корневых сертификатов Trusted Root Certification Authorities.

Для подчиненных и выдающих CA необходимо будет сформировать запрос на сертификацию, который будет обрабатываться родительским CA. После копирования установочных файлов на сервер мастер выдает на экран страницу запроса сертификата CA Certificate Request Page, приведенную на экране 3.

Экран 3. Страница запроса сертификата CA Certificate Request Page

Поскольку корневой и подчиненный CA в нашем случае отключены от локальной сети, передать запрос непосредственно на CA невозможно, так что следует выбрать сохранение запроса в файл Save the request to a file и ввести имя файла на флэш-накопителе. Мастер сохранит запрос в текстовом файле. Для завершения настройки серверов SUBCA и ISSUING нужно выполнить следующие шаги:

1. Вставить флэш-накопитель в сервер CA родительского уровня. С помощью утилиты Certreq (Certificate Request), расположенной в папке system32, передать запрос сертификации на CA. Запустить командный интерпретатор cmd.exe и, в зависимости от уровня CA, выполнить одну из приведенных ниже команд. Для SUBCA:

   CERTREQ -config "ROOTCAHP Root CA" a:SubCA.req
   
   Для ISSUING выполните 
   
   CERTREQ -config "SUBCAHP Subordinate CA" a:IssueCA.req

   ключ -config указывает утилите, CA какого уровня следует использовать. Имя слева от обратной косой черты указывает имя сервера, а справа - имя CA. После выполнения команд будет выдан идентификатор запроса (Request ID number), который следует сохранить (запомнить).
2. Открыть оснастку Certificate Authority на CA родительского уровня. В ней будут представлены четыре контейнера: отозванные сертификаты Revoked Certificates, выданные сертификаты Issued Certificates, отложенные запросы Pending Requests и отвергнутые запросы Failed Requests. Выберите контейнер отложенных запросов Pending Request - в нем вы увидите запрос, сформированный CERTREQ. Если было сформировано несколько запросов, то для определения нужного запроса следует воспользоваться сохраненным значением, определенным в пункте 1. Щелкните правой кнопкой мыши на запросе и в меню Tasks выберите Issue, после чего закройте MMC.
3. Запустить командный интерпретатор cmd.exe и, в зависимости от уровня CA, выполнить одну из приведенных ниже команд. Для SUBCA:

   CERTREQ -retrieve -config "ROOTCAHP Root CA" 2
   
    a:SubCA.crt a:chain.p7b

   Для ISSUING, введите

   CERTREQ -retrieve -config "SUBCAHP Subordinate CA"
   
    4 a:SubCA.crt a:chain.p7b

   Ключ -retrieve сообщает утилите о необходимости загрузить и сохранить выданный сертификат с информацией о цепочке сертификации в файлы. В приведенном выше примере номера запросов, сохраненные из пункта 1, - это 2 и 4. После номеров запроса указываются имена файлов - файл, в котором будет сохранен сертификат, и файл для сохранения информации о цепочке сертификации. Для файлов сертификатов необходимо использовать расширение .crt, а для цепочек сертификации - .p7b. Для завершения сертификации перенесите эти файлы на CA.
4. Запустить оснастку Certificate Authority, щелкнуть Tools, выбрать Install CA Sertificate и в диалоговом окне открыть сохраненный на флэш-накопителе файл chain.p7b. Поскольку сервер SUBCA отключен от локальной сети, попытка проверки файла CRL будет неудачной, при этом система выдаст запрос на продолжение сертификации. Нажмите OK. Теперь в иерархии Certificate Authority появится красный флажок вместо красной точки.

Установка выдающего CA завершена. При установке промежуточного CA придется выполнить почти те же самые действия, что и для корневого CA. Потребуется отредактировать реестр для настройки срока действия сертификата, скопировать CRL и сертификат в папку общего доступа CertEnroll и обновить адреса CDP и AIA таким образом, чтобы они указывали на доступный Web-сервер и AD для доступа к этим ресурсам. Эти шаги совпадают с теми, которые были выполнены для специальной настройки корневого CA. Просто необходимо заменить информацию о промежуточном CA информацией о корневом CA. Теперь иерархия CA полностью сформирована и можно начинать обработку запросов сертификации.

Я надеюсь, что эта статья поможет читателям разобраться с вопросами реализации простой иерархии CA, которая может использоваться, например, для организации цифровой подписи электронной почты. Формирование собственного центра сертификации — это нетривиальная задача. Необходимо разобраться, каким образом устанавливаются службы CA, применяемые для генерации цифровых сертификатов, а также наборов политик и процедур, управляющих использованием технологии CA в организации. Необходимо изучить отношения между СА, сами сертификаты, назначение инструментов, таких как CRL и CDP, и можно начинать формировать и эксплуатировать собственный CA.

Джозеф Нойбауэр (joseph.neubauer@hp.com) — старший технический консультант компании HP, специализирующийся на проблемах Windows и Microsoft Exchange Server.

Использование трехуровневой структуры центра сертификации

Часто возникает вопрос, почему при построении центра сертификации (Certificate Authority, CA) следует использовать трехуровневую иерархию, а не ограничиться, скажем, двумя или одним уровнем иерархии. Во-первых, корневой CA должен выдавать сертификаты исключительно и только промежуточным CA. Правомочность всех остальных сертификатов в цепочке сертификации зависит от сохранности и целостности корневого сертификата. Если закрытый ключ корневого сертификата потерян, украден, поврежден или скомпрометирован любым другим способом, все остальные сертификаты в цепочке сертификации становятся просто бесполезными. Создавая иерархическую систему сертификации, вы получаете возможность разместить корневой CA вне общей сети и обеспечить его защиту на физическом уровне. Во-вторых, благодаря использованию промежуточных CA можно применять различные политики сертификации для разных групп пользователей. Применение различных серверов CA может оказаться полезным, например, в случае работы в удаленных географических регионах с какими-либо ограничениями в областях бизнеса, управления и законодательной базы. Некоторые регионы имеют более высокие политические риски. Когда CA выдает сертификат, CA задает срок действия сертификата. Если существует риск компрометации сертификата или, что еще хуже, риск компрометации CA, использование сертификатов с более коротким сроком действия может быть предпочтительным. Построение архитектуры с несколькими уровнями промежуточных CA позволяет гибко управлять сроком действия сертификатов в разных странах в различных частях света. И наконец, использование достаточно числа выпускающих CA позволяет распределить нагрузку при необходимости обработки большого количества сертификатов.

Таблица 1. Схема принятия решения о количестве CA

Таблица 2. Параметры установки CA

Таблица 3. Подстановочные значения HTTP для CDP и AIA