 |
|
|
|
Установка цепочки серверов сертификации как часть внедрения PKI в домене. Часть 2
Установка цепочки серверов сертификации В первой части статьи мы говорили о типах центров сертификации (Certificate Authority, СА), их операционных параметрах и рассматривали установку и настройку корневого сервера сертификации. Сегодня мы займемся установкой промежуточного и выпускающего СА – для них процесс имеет свои особенности, которые надо учитывать при развертывании всей цепочки серверов. Установка промежуточного СА (SubCA) Так же, как и корневой, этот СА является изолированным, поэтому не должен быть членом домена. Убедитесь, что вы окончательно определились с именем сервера (в нашем случае это SubCA), поскольку после установки служб сертификации изменить его будет также нельзя. Несмотря на то что промежуточный СА является подчиненным по отношению к корневому и наследует многие параметры, нам все равно потребуется перед установкой подготовить файл capolicy.inf и поместить его в %Systemroot%. Сделать это необходимо для того, чтобы позволить промежуточному СА использовать политики выпуска сертификатов (issuing policies). По умолчанию такая возможность отсутствует. Поэтому содержимое файла будет несколько отличаться от того, который использовался для установки корневого СА. В первой части статьи было сказано, что промежуточный СА используется, в частности, для назначения операционных политик. В сертификатах конечных субъектов политика указывает на условия, при которых сертификат был выпущен, и на цели, для которых он может быть использован. Вы можете задавать для различных СА различные политики выпуска сертификатов, которые определяются посредством их OID (object identificator). OID представляет собой серию разделенных точками чисел, например 2.5.29.32.0, и используется для однозначной идентификации объекта в каталогах, организуемых в соответствии с международными рекомендациями X.501, которые регламентируют построение каталогов при взаимодействии открытых систем. Свой OID для предприятия нужно регистрировать, если возникает необходимость занесения в сертификаты открытых ключей сведений о правовых отношениях, при которых электронный документ имеет юридическую силу. Зарегистрировать свой OID можно или на сайте iana.org (при этом OID вашей организации будет начинаться на 1.3.6.1.4.1) или обратиться в ЗАО «Центральный телеграф», который является регистрирующей организацией для российской ветви международных идентификаторов объектов (OID префикс 1.2.643). Примечательно, что на сайте телеграфа я не нашел упоминания о такой услуге, однако по ссылке из [1] можно найти нужные контакты. Список уже зарегистрированных в российской ветке OID можно посмотреть по той же ссылке. Кроме того, существуют и зарезервированные (или «общие) OID (как в примере выше). Несмотря на то что в нашем примере мы не будем использовать никаких операционных политик, все же надо разрешить промежуточному СА обрабатывать политики выпуска сертификатов, чтобы можно было в дальнейшем применять их на нижележащих СА в случае необходимости. Для этого существует политика с OID=2.5.29.32.0. Поэтому наш файл capolicy.inf будет выглядеть следующим образом: [Version] Signature= "$Windows NT$" [PolicyStatementExtension] Policies = AllIssuancePolicy Critical = FALSE [AllIssuancePolicy] OID = 2.5.29.32.0 Если вы обратитесь к первой части статьи [1] и посмотрите на рисунок 2 (пример самоподписанного сертификата корневого СА), то в информации о сертификате в разделе «This certificate is intended for the following purpose(s):» (этот сертификат предназначен для следующих целей) можно увидеть два пункта: All issuance policies и All application policies. Корневой СА всегда выпускает сертификат, который разрешает применение операционных политик; вышеприведенный текст файла capolicy.inf позволяет сделать это и для подчиненного СА. Для установки служб сертификации нам потребуется сертификат корневого СА и его CRL. Их надо забрать с компьютера RootCA (напомню, что файл сертификата RootCA_RootCA.crt находится в папке C:\CAConfig, а файл RootCA.crl в папке C:\WINDOWS\system32\CertSrv\CertEnroll), перенести на компьютер SubCA и импортировать в локальное хранилище сертификатов. Импорт делается командой: certutil –addstore –f Root RootCA_RootCA.crt certutil –addstore –f Root RootCA.crl Можно воспользоваться оснасткой Certificates (сертификаты). В меню «Администрирование» панели управления она отсутствует, и запустить ее можно, только добавив через консоль mmc.exe, выбрав при инициализации раздел «computer account» (учетная запись компьютера). Выбрав в дереве слева ветвь Certificates надо в меню «View -> Options» («Вид -> Параметры») в разделе Show the following (также показывать) включить опцию Physical certificate stores (физические хранилища). Затем раскрыть ветки «Trusted root certification authorities -> Registry -> Certificates» («Доверенные корневые центры сертификации -> Реестр -> Сертификаты»). Нажать в правом окне правую кнопку мыши, из контекстного меню выбрать «All Task -> Import» («Все задачи -> Импорт») и далее следовать указаниям мастера. В появившемся окне обратите внимание на тип отображаемых файлов. Получившийся результат представлен на рис. 1.
Рисунок 1. Сертификат корневого СА в локальном хранилище сертификатов Обратите внимание, что импортированный CRL тут не отображается. Чтобы проверить его наличие в локальном хранилище, можно воспользоваться командой: certutil –verifystore root После перечисления хранящихся локально сертификатов идет перечисление CRL – там мы должны увидеть информацию о нашем CRL:
Важно: процедуру импорта нужно будет повторять каждый раз при обновлении CRL и сертификата вышестоящего СА. Теперь можно приступать непосредственно к установке служб сертификации. Так же, как и для RootCA, сначала имеет смысл установить компоненты IIS и ASP.NET, чтобы иметь возможность в случае необходимости воспользоваться выпуском сертификатов через веб-интерфейс. Установка во многом будет похожа на установку корневого СА. На первом шаге надо будет выбрать тип СА – в нашем случае это Stand-Alone Subordinate CA (изолированный подчиненный центр сертификации) – и установить опцию use custom setting to generate the key pair and CA certificate (использовать специальные параметры для генерации пары ключей и сертификата ЦС). На следующем шаге оставляем все без изменений, кроме длины ключа шифрования – его стоит выбрать в 2048 бит. В качестве имени СА на следующем шаге вводим имя SubCA, в поле Distingueshed name suffix (суффикс отличительного имени) вводим информацию об операционном домене – в нашем случае это, так же как и для RootCA, будет DC=Dedicated,DC=Root. Обратите внимание, что поле Validity Period (период действия) затенено и в нем содержится Determined by parent CA (определяется вышестоящим СА). Шаг Certificate Database Setting (параметры базы данных для сертификатов) оставляем без изменений, а вот на следующем шаге мы должны решить, на какой СА отправлять запрос сертификата (ведь мы устанавливаем подчиненный СА) или же сохранить его в файл для дальнейшей ручной обработки. Поскольку и устанавливаемый, и корневой СА предполагаются отключенными от сети, то мы выбираем второй вариант и сохраняем запрос в файл c:\SubCA.req. Нажав «Далее» и согласившись на временную остановку служб IIS, мы наблюдаем за установкой компонентов, которая оканчивается сообщением, представленным на рис. 2. В нем говорится о том, что установка не будет завершена до тех пор, пока по сохраненному в файле c:\SubCA.req запросу не будет выпущен сертификат родительским СА (в нашем случае это RootCA). Этот сертификат затем надо будет установить через оснастку Certification Authority (центр сертификации). Нажимаем «ОК» и дожидаемся окончания процесса.
Рисунок 2. Сообщение с инструкциями для завершения процесса установки СА Теперь открываем диск С:\ и видим там файл SubCA.req. Этот файл содержит запрос сертификата, и с ним можно поступить двумя способами:
Воспользуемся первым способом. Итак, переносим любым доступным способом файл запроса на RootCA и запускаем оснастку Certification Authority. Выбрав слева RootСА, нажимаем на нем правой кнопкой мыши и выбираем «All Task -> Submit new request» («Все задачи -> Выдать новый запрос»). Далее открываем сформированный чуть выше файл запроса и переходим в ветку Pending Reguest (запросы в ожидании) в левой части окна. При этом в правой части отображаются все запросы, ожидающие обработки. Поскольку наш СА – изолированный, то он не производит выпуск сертификатов автоматически – все запросы должны быть обработаны вручную. Поэтому в правой части окна на запросе надо нажать правую кнопку мыши и выбрать «All Tasks -> Issue» («Все задачи -> Выпустить»). Тем самым мы выпускаем сертификат, запрос исчезает из ветки Pending Reguest, а выпущенный сертификат помещается в ветку Issued certificates (выданные сертификаты). Перейдя в эту ветку в правой части, мы видим, что сертификат выпущен, нам остается теперь только просмотреть его (на предмет корректности срока действия), экспортировать и доставить на подчиненный СА. При просмотре сертификата перейдите на вкладку Details (состав) и нажмите внизу кнопку Copy to file (копировать в файл). Запустится мастер экспорта сертификата, в котором в качестве типа экспортируемого сертификата следует выбрать Cryptographic Message Syntax Standard – PKCS#7 Certificates (.P7B), установить опцию the Include all certificates in the certification path if possible (включить по возможности все сертификаты в путь сертификата), указать место, куда будет сохранен файл сертификата и его имя. В конце работы мастера в сводной информации обратите внимание на строку Export keys: No (экспорт ключей: нет). Это говорит о том, что файл сертификата не будет содержать закрытый ключ. Этот ключ сформирован и хранится на том СА, с которого получен файл запроса сертификата. Поэтому о безопасности файла сертификата можно не беспокоиться. Полученный файл теперь нужно перенести на SubCA, а RootCA можно выключить – он больше не понадобится до тех пор, пока не наступит время обновления CRL. На SubCA теперь надо запустить оснастку Certification Authority. Как видим, в дереве оснастки сервер SubCA помечен как неработающий, поскольку он пока еще не содержит собственного сертификата. Нажимаем на нем правой кнопкой мыши и выбираем «All Tasks -> Install CA certificate» («Все задачи -> Установить сертификат ЦС»). Указываем файл с сертификатом, после чего можно из контекстного меню выбрать «All Tasks -> Start service» («Все задачи -> Запуск службы»). Если все прошло удачно, службы сертификации должны запуститься и в оснастке SubCA станет помечен зеленым значком. На этом установку можно считать законченной. Но перед тем как начать использовать установленный СА, следует провести его конфигурирование. Процесс практически ничем не отличается от описанной в первой части статьи настройки корневого СА за исключением сроков: для подчиненного СА можно задать несколько меньший интервал публикации CRL и в реестре значение ValidityPeriodUnits сделать равным 5, чтобы SubCA мог выдавать сертификаты со сроком действия в 5 лет. После завершения всех настроек не забудьте перезапустить службу сертификации на компьютере. Установка СА предприятия (EntCA) Теперь мы подошли к конечному звену в цепочке серверов сертификации. До сих пор никаких изменений в Active Directory сделано не было, и еще есть возможность безболезненно что-то поправить. Это будет весьма сложно после того, как мы закончим установку СА предприятия и он начнет функционировать. Надо также иметь в виду то, что с появлением корпоративного сервера сертификации поведение контроллеров домена при различных режимах функционирования домена Windows 2000 и Windows 2003 отличается. В первом случае контроллеры домена автоматически начинают пытаться получить сертификат контроллера домена, а во втором – подчиняются настройкам групповой политики, в которой по умолчанию автоматическое получение сертификата контроллера домена отключено. Перед установкой служб сертификации компьютер должен быть членом домена, желательно, чтобы это был корневой домен и компьютер имел статический IP-адрес, а служба доступа к файлам и принтерам была включена. Если домен работает под управлением Windows 2000, на контроллерах домена должен быть установлен Service Pack 3 и, кроме того, потребуется сделать апгрейд схемы до уровня функциональности Windows Server 2003. Настоятельно не рекомендуется размещать службы сертификации на компьютере, уже выполняющем какие-либо функции в домене – например, на файловом сервере или контроллере домена. Установка выполняется из-под учетной записи пользователя, имеющего права Enterprise Admin. Для установки потребуются сертификаты и файлы CRL с вышележащих СА. Как их получить, было рассмотрено в предыдущем разделе. Сначала надо распространить в домене сертификат корневого СА. Члены домена затем автоматически добавят его в локальное хранилище доверенных сертификатов. Во время установки SubCA мы это делали вручную, в домене же можно воспользоваться доменными политиками. Обратите внимание на то, что здесь требуется лишь сертификат корневого СА, а не промежуточного. Чтобы сделать это, в том домене, где будет впоследствии установлен СА предприятия, откройте доменную политику по умолчанию (Default Domain Policy). Раскройте последовательно узлы: «Default Domain Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies» («Политика Default Domain Policy -> Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Политики открытого ключа»). Щелкните правой кнопкой мыши на Trusted Root Certification Authorities (доверенные корневые центры сертификации) и выберите Import (импорт). С помощью мастера импортируйте сертификат корневого СА, который должен появиться в списке справа (см. рис. 3).
Рисунок 3. Распространение в домене сертификата корневого СА через групповую политику Как вы помните, на этапе конфигурирования корневого и подчиненного СА мы задавали точки распространения CRL и AIA. Если посмотреть на рисунок 3 в первой части статьи, то видно, что в качестве таковых мы использовали LDAP-точку и общую папку. Теперь надо позаботиться, чтобы в этих точках были доступны сертификаты СА и файлы с CRL (файлы RootCA_RootCA.crt, RootCA.crl, SubCA_SubCA.crt, SubCA.crl). Начнем с более простого – с общей папки. На компьютере EntCA создаем папку с именем CDP, помещаем в нее вышеназванные файлы и открываем ее для общего доступа. Причем уровень доступа должен разрешать чтение для группы Everyone (все) (не забывая и про NTFS-разрешения тоже). Импорт этих файлов в Active Directory проводится с помощью команды certutil.exe с компьютера EntCA следующим образом: certutil -dspublish -f RootCA_RootCA.crt RootCA certutil -dspublish -f SubCA_SubCA.crt SubCA certutil -dspublish -f RootCA.crl RootCA RootCA certutil -dspublish -f SubCA.crl SubCA SubCA Разумеется, команды выполняются из той папки, где находятся файлы сертификатов и CRL. Обратите внимание, что в первых двух командах последний параметр RootCA и SubCA обозначают хранилище и совпадение с именами компьютеров случайно. Во вторых двух командах параметры RootCA RootCA и SubCA SubCA обозначают соответственно имя компьютера СА и короткое имя СА (СА sanitized name). В нашем случае эти имена совпадают, а узнать их можно с помощью команды: certutil.exe –cainfo выполненной на соответствующем СА. Чтобы убедиться, что импорт прошел успешно, можно открыть оснастку Active Directory Sites and Services (Active Directory – сайты и службы), в меню View (вид) включить пункт Show Services Node (показать узел служб) и в дереве слева развернуть узел «Services -> Public Key Services». При этом в подразделе AIA должны содержаться сертификаты родительских СА, а в подразделе CDP – созданы подпапки с именами, соответствующими корневому и подчиненному СА (см. рис. 4).
Рисунок 4. Сертификаты вышестоящих СА и их CRL импортированы в Active Directory Теперь надо убедиться, что указанные в сертификате подчиненного СА точки CDP доступны. Для этого используется команда: certutil.exe –url SubCA_SubCA.crt По этой команде запустится графическое средство URL Retrieval Tool (инструмент извлечения URL) (см. рис. 5). В поле Retrieve (загрузить) выбираем, что мы хотим проверить – доступность сертификата (из AIA) или доступность CRL (из CDP), и нажимаем кнопку Retrieve (загрузить). Если все в порядке, то в верхнем поле должен появиться статус Verified (проверено) напротив каждой из указанных в сертификате AIA или CDP. Если в каком-то поле появится статус Failed (ошибка), то надо принять меры. Например, если у вас файл сертификата называется SubCA_SubCA.crt, а происходит поиск файла SubCA.crt, то можно переименовать исходный файл.
Рисунок 5. Проверка сертификата с помощью URL Retrieval Tool На этом подготовительный этап завершен. Внимание! Вышеприведенные процедуры должны будут повторяться по мере обновления сертификатов и CRL-файлов родительских СА. Теперь можно приступить непосредственно к установке служб сертификации. Файл capolicy.inf нам не потребуется, так как мы не собираемся указывать для СА никаких операционных политик. Однако установка служб IIS и ASP.NET настоятельно рекомендуется для возможности проводить выпуск сертификатов посредством веб-интерфейса. Процесс установки уже нам знаком. Обратите внимание, что теперь при выборе типа СА нам доступны все 4 типа, из которых мы выбираем Enterprise Subordinate CA (подчиненный ЦС предприятия) и, как и раньше, устанавливаем опцию use custom setting to generate the key pair and CA certificate. На следующем шаге выбираем желаемую длину ключа и не устанавливаем опцию Allow this CSP to interact with the desktop (если используете стандартный Microsoft CSP). Далее задаем имя нашему СА (EntCA) и обращаем внимание, что поскольку компьютер является членом домена, поле distinguished name suffix уже заполнено. На следующем шаге мы видим, что опция stores configuration information in shared folder (хранить информацию о конфигурации в общей папке) не выбрана. Она нужна в случае, если клиент не может получить сертификат через групповую политику или веб-интерфейс. Поскольку у нас на этом сервере уже есть общая папка, то на всякий случай имеет смысл указать ее в качестве места хранения конфигурационной информации. На следующем шаге сохраняем запрос сертификата в файл EntCA.req и завершаем установку. Теперь мы должны вручную выпустить сертификат для нашего корпоративного СА по файлу запроса. Процедура полностью идентична рассматриваемой выше, только запрос должен быть обработан не на корневом СА, а на подчиненном (SubCA). В результате мы должны получить файл сертификата для EntCA и установить его. Перед установкой имеет смысл проверить файл сертификата командой: certutil.exe –url <имя файла сертификата> Конфигурирование СА практически идентично тому, что мы делали ранее. Необходимо задать точки распространения CRL и AIA, выбрать период публикации CRL и определиться, нужны ли нам delta-CRL. При выборе интервалов публикации для CRL стоит вспомнить о рекомендациях, которые давались по этому поводу в первой части статьи. В качестве точек публикации CRL и AIA задаются те же самые места, что и в СА уровнями выше, однако следует задать еще одно расположение, которое будет совпадать с местом \\EntCA\CDP, но указывать на него локально. То есть если папка CDP лежит в корне диска С, то вариант точки публикации будет следующим: C:\CDP\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl При этом для этого расположения надо сбросить все опции, кроме Publish CRL in this location (опубликовать CRL по данному адресу). Поскольку CRL публикуются автоматически, мы избавляем себя от необходимости вручную перекладывать каждый раз новый CRL из папки CertEnroll в папку C:\CDP. По умолчанию СА будет выпускать сертификаты сроком действия в 1 год, и изменять это положение не нужно. После того как вы сделаете все необходимые настройки и перезапустите службы сертификации, СА будет готов к работе и обслуживанию клиентов. Если вы работаете в домене под управлением Windows 2000, то контроллеры домена автоматически получат сертификат, как только обнаружат присутствие центра сертификации в домене, для домена Windows 2003 ничего не произойдет. В последней части статьи мы рассмотрим, как настроить доменные политики на запрос сертификатов и как настраивать шаблоны сертификатов на корпоративном СА. Кроме того, в заключение немного поговорим о типичных проблемах, которые могут возникнуть во время процесса установки всей цепочки и вариантах их решения.
|
Станислав Шпак
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
