Contents of this directory is archived and no longer updated.

Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf и пост-конфигурационном скрипте. Обязательно прочтите.


Ссылки на другие материалы из этой серии:

В первой части установки Certification Authority мы рассмотрели общие вопросы планирования иерархии центров сертификации для сферических задач в вакууме. Я намерено опустил организационные вопросы, которые тоже должны решаться на этапе планирования и остановился лишь на технических аспектах планирования. Итак, как мы договорились в первой части, у нас будет двухуровневая иерархия с Offline Root CA и Online Issuing  Subordinate CA.

Step 1 — Preparing to install

Примечание: по различым причинам я не описываю процедуру установки и настройки Certificate Services на систему под управлением Windows Server 2003. Многое из изложенного будет справедливо и для Windows Server 2003, но часть из этого не будет справедливо для него.

Предполагается, что компьютер с именем RootCA установлен, обновлён и сконфигурированы параметры безопасности. Данный компьютер будет выполнять роль корневого центра сертификации (Root Certification Authority). Поскольку корневой CA — самая важная точка в иерархии PKI, этот сервер будет нормально выключен и включаться только для следующих целей:

  • Отправка новой заявки на сертификат;
  • Публикация CRL;
  • Обновление сертификата самого CA;
  • Установка обновлений безопасности.

В остальное время он должен быть выключен и физический доступ к нему должен быть ограничен. Данный сервер не будет издавать сертификаты конечным потребителям, поэтому выключенное состояние никак на потребителях не отразится.

Вводные данные для корневого сервера CA:

  • Имя CA — Adatum Class 1 Root Certification Authority;
  • Тип CA — Standalone.
  • Срок действия сертификата CA — 10 лет;
  • Срок действия издаваемых сертификатов — 10 лет;
  • Срок действия Base CRL — 90 дней (3 месяца);
  • Delta CRL публиковаться не будет;
  • Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с: Планирование расширений CDP и AIA;
  • CDP и AIA будут использовать только ссылки на HTTP. LDAP использоваться не будет.
  • OCSP для Offline Root CA предусмотрен.

Step 2 — Installing AD CS role on Offline Root CA

Перед установкой роли AD CS, необходимо создать конфигурационный файл, который будет использоваться установщиком роли. Для этого в папке %systemroot% необходимо создать файл с именем CAPolicy.inf и внести в него следующий текст:

[Version]
Signature= "$Windows NT$"

[certsrv_server]
; Устанавливаем длину ключа, которая будет использоваться
; *только* при обновлении сертификата CA
RenewalKeyLength = 2048
; Устанавливаем срок действия обновлённого сертификата.
; Будет использоваться *только* при обновлении сертификата CA
RenewalValidityPeriodUnits = 10
; Устанавливаем единицу измерения для предыдущего параметра
RenewalValidityPeriod = years
; Устанавливаем периодичность публикации CRL в 90 дней (или 3 месяца)
CRLPeriodUnits = 90
CRLPeriod = days
; Устанавливаем срок продления CRL. Фактический срок действия CRL для клиентов увеличивается на
; на заданный период, который в нашем случае равен 2 неделям. Это означает, что сервер CA будет
; публиковать новый CRL каждые 90 дней, а срок действия этого CRL будет 104 дня. Это даст
; администраторам возможность успеть забрать новый CRL с сервера и распространить его в нужные локации
CRLOverlapUnits = 2
CRLOverlapPeriod = weeks
; Отключаем публикацию Delta CRL
CRLDeltaPeriodUnits = 0
CRLDeltaPeriod = hours
; Включаем дискретные алгоритмы для подписей. Не включайте его если у вас есть клиенты под управлением
; Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
;AlternateSignatureAlgorithm = 1

Примечание: конфигурационный файл должен обязательно называться CAPolicy.inf и обязательно храниться в %systemroot%. Другие имена и локации файла не допускаются, иначе он попросту будет проигнорирован. Данный файл доступен для скачивания по ссылке в конце поста.

Когда конфигурационный сохранён в нужном месте, можно приступать к установке роли CA. Для этого запустите Server Manager, перейдите на секцию Roles и нажмите Add Roles. После этого запустится мастер установки ролей.

Примечание: если у вас используется HSM (Hardware Security Module), его драйвер должен быть установлен заранее. И на шаге 8 в списке криптопровайдеров необходимо выбрать CSP производителя вашего HSM.

Примечание: в ходе установки роли AD CS на шаге 9 вместо Adatum укажите название вашей компании. Места, в которых необходимо прописать свои данные заключены в фигурные скобки — {}.

  1. На странице Before You Begin вы можете ознакомиться с информацией об этом мастере. После ознакомления нажмите Next.
  2. На странице Select Roles выберите Active Directory Certificate Services и нажмите Next.
  3. На следующей странице прочтите вводную информацию о роли AD CS и нажмите Next.
  4. На странице Role Services убедитесь что установлен чек-бокс только напротив Certification Authority и нажмите Next.
  5. На странице Setup Type выберите Standalone. Поскольку компьютер не является членом домена, Enteprise нам недоступен. Нажмите Next.
  6. На странице выбора типа CA выберите Root CA и нажмите Next.
  7. На странице Private Key выберите Create a new private key и нажмите Next.
  8. На странице Cryptography выберите следующий криптопровайдер из списка: RSA#Microsoft Software Key Storage Provider
    Установите длину ключа в 2048 бит и алгоритм подписи в SHA1. После чего нажмите Next.
  9. На странице выбора имени CA введите следующее:

    {Adatum} Class 1 Root Certification Authority.

    в поле Distinguished name suffix укажите примерно такое:

    OU=Information Systems,O={Adatum Ltd.},C={LV}

    и нажмите Next.
  10. На странице Validity Period укажите срок действия сертификата. В большинстве случаев 10 лет — наиболее оптимальный срок действия корневого сертификата. Нажмите Next.
  11. На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
  12. На странице Confirmation просмотрите настройки, которые вы указали. Если вы ошиблись на каком-то этапе — вернитесь назад и исправьте ошибку. Если всё правильно, нажмите Install и подождите пока мастер сконфигурирует роль.

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

Примечание: у вас может быть соблазн выбрать более стойкий алгоритм подписи. Например, SHA256 или SHA384. Однако, следует учесть, что предыдущие системы (например, Windows XP/Server 2003) могут испытывать трудности с проверкой подписей с использованием алгоритмов SHA-2. Более подробно можно почитать тут: http://blogs.msdn.com/alejacma/archive/2009/01/23/sha-2-support-on-windows-xp.aspx

Когда мастер установит роль AD CS, вы можете уже запустить оснастку Certification Authority из папки Administrative Tools. Однако, на этом ещё не всё закончилось. Сейчас нам необходимо применить скрипт, который сконфигурирует остальные настройки.

Step 3 — Finalizing Offline Root CA installation

Для настройки следующих параметров можно воспользоваться следующим скриптом (с правкой его под местные условия):

Примечание: места в которых необходимо подставить свои данные заключены в фигурные скобки — {}.

:: Создаём папку в корне диска C, где будут храниться CRT и CRL файлы
md C:\CertData

:: Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_RCA%%8.crl\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%8.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt"

:: Если будет использоваться OCSP для корневого CA, расширение AIA должно выглядеть примерно cледующим образом:
:: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt\n32:http://www.{adatum.com}/ocsp"
:: учтите, что при использовании этого варианта, предыдущую строку требуется закомментировать или удалить
:: а эту строку раскомментировать соответственно.

:: Поскольку мы не можем управлять публикацией CRT файлов, мы его
:: переименовываем в нужное имя и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt {Adatum}_RCA.crt
copy %windir%\system32\CertSrv\CertEnroll\{Adatum}_RCA.crt C:\CertData

:: задаём срок действия издаваемых сертификатов равным 10 лет
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)
certutil -setreg CA\CRLPeriodUnits 90
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2

:: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
:: Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1

:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127

:: Включаем поддержку сертификатов OCSP Response Signing на Offline CA:
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

net stop certsvc && net start certsvc

:: Публикуем новый CRL в новую локацию.
certutil -CRL

Примечание: данный скрипт необходимо запустить только один раз. Скрипт доступен для скачивания по ссылке в конце поста.

Данный скрипт создаст в корне диска C: папку CertData, в которой будут храниться опубликованные списки CRL и файлы сертификатов сервера CA. При этом CRL'ы будут автоматически публиковаться в эту папку, а CRT нет. Это связано с тем, что начиная с Windows Server 2003 мы больше не имеем возможности управлять публикацей файлов CRT. Для этого мы берём файл из оригинальной папки CertEnroll, переименовываем в нужное нам имя и копируем в папку CertData. Здесь я ещё хочу остановиться на построении ссылок в CDP и AIA, поскольку они выглядят предельно ужасно. Давайте разберёмся с этим.

Step 4 — Understanding post-installation script

Возьмём следующую строку:

"65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\Adatum_RCA%%8.crl\n2:http://www.adatum.com/pki/Adatum_RCA%%8.crl"

Как мы видим, данная строка строится из 3-х составляющих:

  1. 65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl
  2. 65:C:\CertData\Adatum_RCA%%8.crl
  3. 2:http://www.adatum.com/pki/Adatum_RCA%%8.crl

Каждое составляющее является отдельной ссылкой, которую видно во вкладке Extensions свойств сервера CA в оснастке CertSrv.msc. Все эти составляющие пишутся в одну строку и разделяются символом новой строки: \n. Парсер CMD автоматически режет строку на куски по знаку новой строки. Когда мы разложили строку на более читабельные ссылки, пора и заняться ими. Первое, что нам бросается в глаза — это циферки перед ссылками. Циферки означают сумму параметров публикации. Т.е. что данная ссылка будет делать, публиковать физический файл, добавляться в расширение сертификатов или в расширение CRL и т.д. Это эквивалентно галочкам во вкладке Extensions. Каждая такая галочка имеет определённый числовой эквивалент (числовое значение). Предлагаю 2 таблички, которые покажут соответствие каждой галочке числовому значению для ссылок в расширении CDP и AIA:

Название галочки в CDP Числовое значение Название галочки в AIA Числовое значение
Publish CRLs to this location. 1

Include in the AIA extension of issued
certificates.

2
Include in the CDP extension of issued certificates. 2

Include in the Online Certificate Status
Protocol (OCSP) extension.

32
Include in CRLs. Clients use this to find Delta CRL locations. 4

 

 
Include in all CRLs. Specifies where to publish in AD DS when publishing manually. 8    
Publish Delta CRLs to this location. 64    
Include in the IDP extension of issued CRLs. 128    

Как видите, для расширения CDP число 65 является суммой чисел 1 и 64. Исходя из таблички мы можем узнать, что ссылка с таким префиксом публикует физические файлы для Base и Delta CRL. А цифра 2 (в третьей ссылке) означает, что эта ссылка будет добавляться в расширение CDP издаваемых сертификатов. Префикс ставится всегда перед самой ссылкой и отделяется от неё двоеточием — :. То же самое и касается ссылок в AIA.

Теперь осталось разобраться со знаками процента (%) и цифрами после них. Например: %windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl. Данные кракозябры представляют переменные, которые вы можете указывать при создании ссылок. Вот ещё одна табличка, которая показывает соответствие переменных их числовым значениям:

Примечание: данные значения справедливы как для расширения CDP, так и AIA.

Переменная в редакторе расширений CDP и AIA Переменная в скрипте Используемое
расширение
<ServerDNSName> %1 CDP/AIA

<ServerShortName>

%2 CDP/AIA

<CaName>

%3 CDP/AIA

<CertificateName>

%4 AIA
<ConfigurationContainer> %6 CDP/AIA

<CATruncatedName>

%7 CDP/AIA

<CRLNameSuffix>

%8 CDP
<DeltaCRLAllowed> %9 CDP

<CDPObjectClass>

%10 CDP

<CAObjectClass>

%11 CDP/AIA

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

Правда, на технетах информация несколько устаревшая, но в целом сгодится для понимания.

Вот и всё, что я хотел рассказать про установку Offline Root CA. В следующей части я расскажу про установку Online Issuing CA и что-нибудь ещё.

Файлы для скачивания:

(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)


Share this article:

Comments:

имя

Вопрос возник, это получается, что мы делаем для главного сервера сертификации самоподписанный сертификат? А можно как-то использовать сторонний сертификат для главного центра сертификации?

Vadims Podāns

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

sacrificeme

Уже который день пытаюсь прийти к правильно настроенному PKI.. Почему мы не прописываем в CAPolicy.inf данные настройки о которых говорилось в статье "CRL Distribution Points и Authority Information Access": [AuthorityInformationAccess] Empty = true [CRLDistributionPoint] Empty = true Зачем мы задаем точки публикации CRL?? Псц, ну нельзя же так, я уже голову сломал почему не проходит авторизация по eToken...

Vadims Podāns

> Почему мы не прописываем в CAPolicy.inf данные настройки о которых говорилось в статье "CRL Distribution Points и Authority Information Access": эти настройки прописываются только для корневых CA под управлением Windows 2000 Server и Windows Server 2003. Начиная с Windows Server 2008, CA больше не добавляет эти расширения в корневые сертификаты. Я ещё раз повторяю, что CDP/AIA в сертификатах указывают на файлы *вышестоящего* CA, которого у корневого нет. Поэтому в корневых сертификатах они не нужны. > Зачем мы задаем точки публикации CRL?? а для остальных сертификатов нужно держать эти расширения.

sacrificeme

Тогда понятно, приношу прощения :) Думал по аналогии настроить CA на WIN2003, трудно работать с VM Windows 2008 много ресурсов потребляют :( По поводу этого текста в постинсталл скрипте: :: Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов. certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_RCA%%8.crl\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%8.crl" certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt Т.е. эти настройки справедливы для выпущенных Рутовым ЦС сертификатов для Подчиненных ЦС. И подчиненные ЦС проверяют цепочку сертификатов, основываясь на CRL и CDP заданные Рутовым ЦС?

Vadims Podāns

Да. Эти настройки будут отражены в сертификатах, которые будут выпущены корневым CA.

Дмитрий

Мучает вопрос, как всетаки правильно Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1 или Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1 Это тоже самое, названое по разному или это разные вещи? По ссылке ниже, сам Брайан Комар утверждает, что извиняйте ребята, в моей книжке косячок, пока писал книгу, MS изменило название атрибута. Или я его не правильно понял? http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/4256a27f-29ee-42a1-b687-ad3c21e04c0c

Vadims Podāns

Да, я видел этот пост, но не совсем уверен в этом, поскольку никто не доставил пруфов. У меня есть один сервер CA с включенным CNG и собранный с DiscreteSignatureAlgorithm и вроде как работает вполне ожидаемо. Я попробую уточнить у Брайана этот вопрос.

Дмитрий

А что конкретно определяет DiscreteSignatureAlgorithm? AlternateSignatureAlgorithm - вроде как разрешает использование формата PKCS#1 V2.1 см. по ссылке ниже. Про DescreteSignatureAlgorithm почему то не упоминают в описании синтаксиса CAPolicy.inf для Win2008, с другой стороны это не официальное описание. AlternateSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1 signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes the PKCS#1 V2.1 signature format. http://blogs.technet.com/b/askds/archive/2009/10/15/windows-server-2008-r2-capolicy-inf-syntax.aspx

Дмитрий

При AlternateSignatureAlgorithm=1, сертифика ЦС и издаваемые им сертификаты подписываются подписью в формате PKCS#1 V2.1, которая не понимается на XP и Win2003 :( Так что лучше ставить AlternateSignatureAlgorithm=0

Valentin

Проделал все во второй раз по статье. Косяк однако в скрипте с процентами - ничего cmd не вырезает, вот собственно: Old Value: CRLPublicationURLs REG_MULTI_SZ = 0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 1: 8:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 CSURL_ADDTOCRLCDP -- 8 2: 6:http://%1/CertEnroll/%3%8%9.crl CSURL_ADDTOCERTCDP -- 2 CSURL_ADDTOFRESHESTCRL -- 4 3: 6:file://%1/CertEnroll/%3%8%9.crl CSURL_ADDTOCERTCDP -- 2 CSURL_ADDTOFRESHESTCRL -- 4 New Value: CRLPublicationURLs REG_MULTI_SZ = 0: 65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 1: 65:C:\CertData\PF_RCA%%8.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 2: 2:http://www.pf.loc/pki/PF_RCA%%8.crl CSURL_ADDTOCERTCDP -- 2

Valentin

Проверил, действительно - правильно будет так: ertutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%3%8%9.crl\n65:C:\CertData\PF_RCA%8.crl\n2:http://www.pf.loc/pki/PF_RCA%8.crl" certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://www.pf.loc/pki/PF_RCA%4.crt" Вот тому подтверждение: C:\Users\Administrator>certutil -setreg CA\CRLPublicationURLs "65:%windir%\syste m32\CertSrv\CertEnroll\%3%8%9.crl\n65:C:\CertData\PF_RCA%8.crl\n2:http://www.pf. loc/pki/PF_RCA%8.crl" SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\PF RootCA\CRLPublication URLs: Old Value: CRLPublicationURLs REG_MULTI_SZ = 0: 65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 1: 65:C:\CertData\PF_RCA%%8.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 2: 2:http://www.pf.loc/pki/PF_RCA%%8.crl CSURL_ADDTOCERTCDP -- 2 New Value: CRLPublicationURLs REG_MULTI_SZ = 0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 1: 65:C:\CertData\PF_RCA%8.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 2: 2:http://www.pf.loc/pki/PF_RCA%8.crl CSURL_ADDTOCERTCDP -- 2 CertUtil: -setreg command completed successfully. The CertSvc service may need to be restarted for changes to take effect. C:\Users\Administrator>certutil -setreg CA\CACertPublicationURLs "1:%windir%\sys tem32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://www.pf.loc/pki/PF_RCA%4.crt" SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\PF RootCA\CACertPublicat ionURLs: Old Value: CACertPublicationURLs REG_MULTI_SZ = 0: 1:C:\Windows\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt CSURL_SERVERPUBLISH -- 1 1: 2:http://www.pf.loc/pki/PF_RCA%%4.crt CSURL_ADDTOCERTCDP -- 2 New Value: CACertPublicationURLs REG_MULTI_SZ = 0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt CSURL_SERVERPUBLISH -- 1 1: 2:http://www.pf.loc/pki/PF_RCA%4.crt CSURL_ADDTOCERTCDP -- 2 CertUtil: -setreg command completed successfully. The CertSvc service may need to be restarted for changes to take effect.

Vadims Podāns

> Косяк однако в скрипте с процентами - ничего cmd не вырезает не торопитесь. Проценты CMD вырезает, если выполнять скрипт из CMD/BAT файла. Если же код выполнять из консоли — тогда вырезать не будет. Это особенности CMD.

Emulty

С разбегу разобраться со всеми особенностями и принципами работы сертификатов и служб сертификации, никак не получается. Мозг вскипает буквально сразу. Приходится перечитывать все по нескольку раз, и все-равно картина полностью в голове не проясняется. Писец товарищи!

www.google.com/accounts/o8/id?id=AItOawloILTNcys-q0eoXBE2OgikRhyRfI4jpE4

Вадим, не могу понять почему дублируются (на мой взгляд) некоторые настройки. Например, в CAPolicy.inf есть параметр CRLPeriodUnits = 90 и его же предлагается задать в post-install скрипте. С какой целью они существуют одновременно? Также не уверен, что правильно понимаю назначение параметра в CAPolicy.inf RenewalValidityPeriodUnits = 10. Аналогичное значение в 10 лет задается при установке роли и ещё в post-install скрипте CA\ValidityPeriodUnits 10. Очевидно то, что задается в CAPolicy.inf (согласно Вашему комментарию) относится именно к сертификату, создаваемому в результате обновления первоначального сертификата. Срок действия первоначального сертификата задается во время установки роли. А последний параметр, задаваемый в post-install скрипте определяет время действия сертификатов, выдаваемых от имени Root CA для Subordinate CA. Прошу подтвердить мои предположения. Спасибо.

Vadims Podāns

1) да, они дублируются. В принципе, CRL Period units можно определять только в post-installation скрипте. Я дублирую их на случай если я что-то забуду в post-installation скрипте. 2) RenewalValidityPeriod относится только к сертификату корневого CA. единственное место где можно определить срок действия этого сертификата при обновлении — CAPolicy.inf. ValidityPeriodUnits, который определяется пост-установочном скрипте относится к максимальному сроку действия *издаваемых* сертификатов.

www.google.com/accounts/o8/id?id=AItOawloILTNcys-q0eoXBE2OgikRhyRfI4jpE4

Т.е. получается, что с одной стороны capolicy.inf задает настройки для установщика роли, с другой стороны из него же настройки подхватываются при старте сервиса CA. Какая настройка имеет больший приоритет? Post-installation скрипт перекроет настройки из capolicy.inf и значения параметров из скрипта будут активны? Тогда как же параметр RenewalValidityPeriod, он ведь получается подхватывается из capolicy.inf. Единственное разумное объяснения для себя могу найти в том, что это зависит от каждого конкретного параметра, что то берется всегда из capolicy.inf, а что то сначала также из файла, а дальше может переопределяться в реестре.

www.google.com/accounts/o8/id?id=AItOawloILTNcys-q0eoXBE2OgikRhyRfI4jpE4

Вадим, в этот раз сам нашел лаконичный ответ на свой вопрос. Although the settings are replicated in both capolicy.inf and in the post-installation script, the settings in CAPolicy.inf are read only at installation and during renewal. The post-installation script can be executed at any time to reset CA configuration settings to the settings recorded in the script. Спасибо за помощь!

Ruslan V. Karmanov

Вадимс, Ты в тексте упоминаешь SHA-3, его ещё нет. Конкурс до 2012 года идёт, правленный MD6 пока не победил, хотя имеет все шансы.

Dima Fedorov

Я правильно понимаю, что в случае размещения на внешнем Web-сервере, должен быть еще путь на шару? Что-то вида "65:file\\{ServerName}/pki/{Adatum}_RCA%%8.crl" в конце второй строки скрипта. А crt файл на Web-сервер надо копировать ручками.

Vadims Podāns

да. Только не 65:file\\, а 65:file://\\{servername}\... или просто 65:\\{servername}\...

Dima Fedorov

Огромное спасибо за Ваши статьи. Еще один вопросик. У нас указано, что CRL публикуются раз в 90 дней. Это означает, что мы раз в квартал должны запускать наш корневой сервер и публиковать список отзыва. Поскольку все равно это будет делаться руками, я хочу сделать примерно следующее: - на корневом сервере "C:\CertData" зашарить для всех на чтение, - после запуска корневого сервера и выпуска списка отзыва захожу на него со своего Web-сервера и копирую нужный crl. Тогда на шаре на Web-сервере не надо будет делать доступ всем. И еще один вопросик: могу ли я выпускать crl раньше чем через 90 дней?

Vadims Podāns

Я бы не советовал ничего шарить на корневом сервере. Переносите файлы на флешке. > могу ли я выпускать crl раньше чем через 90 дней? можете. Хоть каждый день :)

Виктор Мусатов

Добрый день. Во-первых, спасибо за статьи :) во-вторых, есть вопрос: установил корневой ЦС + выдающий ЦС руководствуясь в основном вшим руководством. Вроде все красиво и работает, но получил проблему. Сертификаты корневого и выдающего ЦС в результате не могут быть проверены на win 2003 и XP, выдается ошибка "the certificate has an nonvalid digital signature" Пробовал апдейты KB938397 и KB968730 - результат нулевой. По некоторым статьям выяснил, что # в названии криптопровайдера указывает на использование CNG, рекомендуется использовать Microsoft Strong Cryptographic Provider - так ли это? P.S. в сертификатах AIA и CDP только http ссылки на crt и crl + ocsp хотел бы узнать, вы не сталкивались с такой проблемой?

Vadims Podāns

Дело в том, что вы использовали новые форматы подписи, которые включаются через AlternateSignatureAlgorithm в CAPolicy.inf. У меня в статье эта часть закомментирована, а в приаттаченном файле ещё нет. Вам же придётся переустанавливать CA и убирать AlternateSignatureAlgorithm отовсюду.

www.google.com/accounts/o8/id?id=AItOawlfEEW5aseVF7qVG53EmaUBFhGRFvDn_vw

Добрый день. Вот мы, по статье публикуем crl корневого ЦС на сайт (переносим раз в 3 месяца файлы на флешке). При этом, в разделе "Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA" - Step 3 , запускаем команду certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA с доменного SubCA сервера. Мы успешно поместили сертификат корневого ЦС в домен. Также у меня публикуется сертификат SubCA в ldap. Я на самом деле хочу видеть в сертификатах (выпущенных как корневым ЦС, так и SubCA) 2 ссылки на crl и crt: первая безоговорочно на http://, вторая на ldap:///. Стоит ли в выпускаемых (корневым ЦС) сертификатах указать ссылку на ldap:/// ? Я бы хотел опубликовать (и руками обновлять) crl корневого ЦС на ldap-сервер (certutil -dspublish CRLFile ??)и в выпускаемом им сертфикатах указать ссылку на ldap:///. Мне кажется, есть смысл иметь второй по списку ссылку на ldap. Прокомментируете? Низкий Вам поклон

Vadims Podāns

Да, я недавно как раз и проектировал PKI, где все CA настроены на публикацию CRT/CRL в LDAP (для себя я не использую LDAP) и включение этих ссылок в сертификаты. В этом случае конфигурация CDP/AIA будет примерно такой (это для корневого CA): certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n1:C:\CertData\XXX_rca%%8.crl\n2:http://%httpcrl%\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10" certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://%httpaia%\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11" Единственное, вам надо будет прописать правильный DSConfig в настройках CA.

www.google.com/accounts/o8/id?id=AItOawlfEEW5aseVF7qVG53EmaUBFhGRFvDn_vw

Просто дополню Вадима конкретной командой, которую необходимо выполнить на RootCA, в случае желания публиковать его crl\crt в ldap: Задаём контекст конфигурации для сервера CA. Контекст конфигурации должен указывать на *корневой домен* текущего леса. certutil -setreg CA\DSConfig "CN=Configuration,DC={adatum},DC={com}" Прошу заметить, что изначально корневой ЦС по сути не был привязан к какому-то конкретному домену, его одного можно было использовать на любом количестве абсолютно не связанных доменах (при этом интересный момент с доверием сертификатов между этими несвязанными доменами интригует). С вводом certutil -setreg CA\DSConfig "CN=Configuration,DC={adatum},DC={com}" наш кореш обретает первую привязку.

Tilerans

Дополнение номер 2: еще для публикации crl\crt нашего Stand-alone RootCA в ldap, помимо CA\DSConfig CN=Configuration,DC={adatum},DC={com} еще надо прописывать CA\DSConfigDN DC={adatum},DC={com}. Информация взята отсюда http://technet.microsoft.com/ru-ru/library/cc783813(WS.10).aspx и касается она Windows 2003. Я на своей 2008R2 тоже прописал, ибо были ошибки в ссылках на ldap:/// наподобии такой: ldap:///CN=Adatum%20Class%201%20Root%20Certification%20Authority,CN=testserver,CN=CDP,CN=Public%20Key%20Services,CN=Services,DC=UnavailableConfigDN?certificateRevocationList?base?objectClass=cRLDistributionPoint Взор на "DC=UnavailableConfigDN" в ссылке! Вот еще: http://technet.microsoft.com/en-us/library/cc737740%28WS.10%29.aspx

Robert

подскажите, не понял " :: Если будет использоваться OCSP для корневого CA, расширение AIA должно выглядеть примерно cледующим образом: :: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt\n32:http://www.{adatum.com}/ocsp" :: учтите, что при использовании этого варианта, предыдущую строку требуется закомментировать или удалить :: а эту строку раскомментировать соответственно. " нельзя публиковать ссылку OCSP и "*.crl"? объясните, если не трудно

Vadims Podāns

Не понял вопроса. Можете пояснить?

Robert

"... :: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt\n32:http://www.{adatum.com}/ocsp" учтите, что при использовании этого варианта, предыдущую строку требуется закомментировать или удалить, а эту строку раскомментировать соответственно ..." приведенный отрывок настраивает ссылку в AIA на OCSP вы говорите что если это значение указывать, то предыдущее нужно закомментировать, не понял, что нужно закомментировать, ссылку на "*.crl"? если да, то печему? спасибо

Vadims Podāns

Нет, вот эту строчку надо закомментировать: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt" и оставить вот эту: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt\n32:http://www.{adatum.com}/ocsp"

Robert

а почему ссылки не могут жить вместе "*.crt" и OCST ? сори за тупые вопросы, но не догоняю

Vadims Podāns

Они могут быть вместе. Просто когда OCSP не используется, то и ссылки на OCSP не указываются. Первая ссылка — только CRT, а вторая — то же самое + ссылка на OCSP.

Robert

Ясно, благодарю за разьяснение

Денис (FMihalych)

Вадимс, доброго времени суток. У меня, как я и ожидал :), появились дополнительные вопросы. 1. Сначала косметический момент. Мы тут говорим о "offline root ca", который издаёт сертификаты только для subca, так? И мы обоснованно отключили в настройках публикацию DeltaCRL. Зачем нам тогда публиковать по локальному пути "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl" с параметром публикации "65"? Не достаточно разве параметра "1"? Или это фича и оснастка просто не даст для обязательного пути отказаться от опции DeltaCRL (я сам пока не пробовал)? Для пути "65:C:\CertData\Kraftway_RCA%%8.crl" в вашем ответе про LDAP в данной ветке обоснованно приведено значение публикации "1", ибо "65" также не имеет смысла в данном случае. 2. Если мы не будем публиковать и проверять сертификаты rootca и subca в LDAP, то будут ли они автоматически добавляться в нужные контейнеры клиентского компьютера при вводе его в домен? 3. Если истечёт время действия и продления CRL, а мы его не опубликуем по путям проверки сертификатов, все цепочки перестанут проверяться и будут давать ошибку или визуально и функционально ничего не изменится? Если второе, то не лучше ли делать период действия CRL поменьше? Ведь при приведённых в статье параметрах при компрометации subca, злоумышленник сможет пользоваться его фукнционалом три с лишним месяца (если я правильно всё понимаю).

Vadims Podāns

1) согласен, но это ни на что не влияет, т.к. от этого Delta CRL'ы публиковаться не будут. 2) да, будут. 3) это зависит от приложения. Некоторые (например, IE, Outlook) будут работать как и раньше, а другие (например, SSTP VPN, RDP) перестанут работать.

Comments are closed.