Вопрос возник, это получается, что мы делаем для главного сервера сертификации самоподписанный сертификат? А можно как-то использовать сторонний сертификат для главного центра сертификации?
Что значит "сторонний"? Видите ли, суть самоподписанного сертификата в том, что его заверяет тот, кто его подписывает. Если кто-то другой заверяет подпись, то это уже не самоподписанный сертификат получается. Т.е. никто не может заверить самоподписанный сертификат кроме того, кто его подписывает. Следовательно, ответ — нет. Другое дело, что вы можете сделать ваш корневой CA подчинённым по отношению к стороннему коммерческому CA за счёт кросс-сертификации (это уже отдельная песня) или не делать себе корневой CA совсем, а сделать свой подчинённый CA, сертификат которого будет издан другим коммерческим CA. Тут вопрос в необходимости этого и толщины вашего кармана, поскольку сделать у себя подчинённый CA по отношению к доверенным публичным CA стоит денег и немалых.
Уже который день пытаюсь прийти к правильно настроенному PKI.. Почему мы не прописываем в CAPolicy.inf данные настройки о которых говорилось в статье "CRL Distribution Points и Authority Information Access": [AuthorityInformationAccess] Empty = true [CRLDistributionPoint] Empty = true Зачем мы задаем точки публикации CRL?? Псц, ну нельзя же так, я уже голову сломал почему не проходит авторизация по eToken...
> Почему мы не прописываем в CAPolicy.inf данные настройки о которых говорилось в статье "CRL Distribution Points и Authority Information Access": эти настройки прописываются только для корневых CA под управлением Windows 2000 Server и Windows Server 2003. Начиная с Windows Server 2008, CA больше не добавляет эти расширения в корневые сертификаты. Я ещё раз повторяю, что CDP/AIA в сертификатах указывают на файлы *вышестоящего* CA, которого у корневого нет. Поэтому в корневых сертификатах они не нужны. > Зачем мы задаем точки публикации CRL?? а для остальных сертификатов нужно держать эти расширения.
Тогда понятно, приношу прощения :) Думал по аналогии настроить 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 заданные Рутовым ЦС?
Да. Эти настройки будут отражены в сертификатах, которые будут выпущены корневым 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
Да, я видел этот пост, но не совсем уверен в этом, поскольку никто не доставил пруфов. У меня есть один сервер 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
Проделал все во второй раз по статье. Косяк однако в скрипте с процентами - ничего 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
Проверил, действительно - правильно будет так: 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.
> Косяк однако в скрипте с процентами - ничего cmd не вырезает не торопитесь. Проценты CMD вырезает, если выполнять скрипт из CMD/BAT файла. Если же код выполнять из консоли — тогда вырезать не будет. Это особенности CMD.
С разбегу разобраться со всеми особенностями и принципами работы сертификатов и служб сертификации, никак не получается. Мозг вскипает буквально сразу. Приходится перечитывать все по нескольку раз, и все-равно картина полностью в голове не проясняется. Писец товарищи!
Вадим, не могу понять почему дублируются (на мой взгляд) некоторые настройки. Например, в CAPolicy.inf есть параметр CRLPeriodUnits = 90 и его же предлагается задать в post-install скрипте. С какой целью они существуют одновременно? Также не уверен, что правильно понимаю назначение параметра в CAPolicy.inf RenewalValidityPeriodUnits = 10. Аналогичное значение в 10 лет задается при установке роли и ещё в post-install скрипте CA\ValidityPeriodUnits 10. Очевидно то, что задается в CAPolicy.inf (согласно Вашему комментарию) относится именно к сертификату, создаваемому в результате обновления первоначального сертификата. Срок действия первоначального сертификата задается во время установки роли. А последний параметр, задаваемый в post-install скрипте определяет время действия сертификатов, выдаваемых от имени Root CA для Subordinate CA. Прошу подтвердить мои предположения. Спасибо.
1) да, они дублируются. В принципе, CRL Period units можно определять только в post-installation скрипте. Я дублирую их на случай если я что-то забуду в post-installation скрипте. 2) RenewalValidityPeriod относится только к сертификату корневого CA. единственное место где можно определить срок действия этого сертификата при обновлении — CAPolicy.inf. ValidityPeriodUnits, который определяется пост-установочном скрипте относится к максимальному сроку действия *издаваемых* сертификатов.
Т.е. получается, что с одной стороны capolicy.inf задает настройки для установщика роли, с другой стороны из него же настройки подхватываются при старте сервиса CA. Какая настройка имеет больший приоритет? Post-installation скрипт перекроет настройки из capolicy.inf и значения параметров из скрипта будут активны? Тогда как же параметр RenewalValidityPeriod, он ведь получается подхватывается из capolicy.inf. Единственное разумное объяснения для себя могу найти в том, что это зависит от каждого конкретного параметра, что то берется всегда из capolicy.inf, а что то сначала также из файла, а дальше может переопределяться в реестре.
Вадим, в этот раз сам нашел лаконичный ответ на свой вопрос. 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. Спасибо за помощь!
Вадимс, Ты в тексте упоминаешь SHA-3, его ещё нет. Конкурс до 2012 года идёт, правленный MD6 пока не победил, хотя имеет все шансы.
косяк. Сейчас уберу.
Я правильно понимаю, что в случае размещения на внешнем Web-сервере, должен быть еще путь на шару? Что-то вида "65:file\\{ServerName}/pki/{Adatum}_RCA%%8.crl" в конце второй строки скрипта. А crt файл на Web-сервер надо копировать ручками.
да. Только не 65:file\\, а 65:file://\\{servername}\... или просто 65:\\{servername}\...
Огромное спасибо за Ваши статьи. Еще один вопросик. У нас указано, что CRL публикуются раз в 90 дней. Это означает, что мы раз в квартал должны запускать наш корневой сервер и публиковать список отзыва. Поскольку все равно это будет делаться руками, я хочу сделать примерно следующее: - на корневом сервере "C:\CertData" зашарить для всех на чтение, - после запуска корневого сервера и выпуска списка отзыва захожу на него со своего Web-сервера и копирую нужный crl. Тогда на шаре на Web-сервере не надо будет делать доступ всем. И еще один вопросик: могу ли я выпускать crl раньше чем через 90 дней?
Я бы не советовал ничего шарить на корневом сервере. Переносите файлы на флешке. > могу ли я выпускать 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 хотел бы узнать, вы не сталкивались с такой проблемой?
Дело в том, что вы использовали новые форматы подписи, которые включаются через AlternateSignatureAlgorithm в CAPolicy.inf. У меня в статье эта часть закомментирована, а в приаттаченном файле ещё нет. Вам же придётся переустанавливать CA и убирать AlternateSignatureAlgorithm отовсюду.
Добрый день. Вот мы, по статье публикуем 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. Прокомментируете? Низкий Вам поклон
Да, я недавно как раз и проектировал 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.
Просто дополню Вадима конкретной командой, которую необходимо выполнить на 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}" наш кореш обретает первую привязку.
Дополнение номер 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
подскажите, не понял " :: Если будет использоваться 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"? объясните, если не трудно
Не понял вопроса. Можете пояснить?
"... :: 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"? если да, то печему? спасибо
Нет, вот эту строчку надо закомментировать: 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"
а почему ссылки не могут жить вместе "*.crt" и OCST ? сори за тупые вопросы, но не догоняю
Они могут быть вместе. Просто когда OCSP не используется, то и ссылки на OCSP не указываются. Первая ссылка — только CRT, а вторая — то же самое + ссылка на OCSP.
Ясно, благодарю за разьяснение
Вадимс, доброго времени суток. У меня, как я и ожидал :), появились дополнительные вопросы. 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, злоумышленник сможет пользоваться его фукнционалом три с лишним месяца (если я правильно всё понимаю).
1) согласен, но это ни на что не влияет, т.к. от этого Delta CRL'ы публиковаться не будут. 2) да, будут. 3) это зависит от приложения. Некоторые (например, IE, Outlook) будут работать как и раньше, а другие (например, SSTP VPN, RDP) перестанут работать.
Comments: