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

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

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

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

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

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

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

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

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Adatum Root CA]
"CRLPeriod"="months"
"CRLPeriodUnits"=dword:00000003
"CRLOverlapPeriod"="weeks"
"CRLOverlapUnits"=dword:00000001
"CRLDeltaPeriod"="Days"
"CRLDeltaPeriodUnits"=dword:00000000
"CRLDeltaOverlapPeriod"="hours"
"CRLDeltaOverlapUnits"=dword:00000000
"CAXchgValidityPeriod"="Weeks"
"CAXchgValidityPeriodUnits"=dword:00000000
"CAXchgOverlapPeriod"="Days"
"CAXchgOverlapPeriodUnits"=dword:00000000
"ValidityPeriod"="Years"
"ValidityPeriodUnits"=dword:00000005

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

net stop certsvc && net start certsvc

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

certutil –CRL

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

Бэкап Certification Authority

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

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

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

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

certutil –backup c:\RootCA_%date%

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

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

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

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

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

Демонтаж Enterprise CA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

certutil –dspublish –f c:\RootCA.cer RootCA
certutil –dspublish –f c:\RootCA.cer SubCA
certutil –dspublish –f c:\RootCA.cer NTAuthCA

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

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

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

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

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

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

Offline CA CRL lifecycle

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

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

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

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