Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в постустановочном скрипте
Ссылки на другие материалы из этой серии:
В предыдущей части (Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA) мы рассмотрели процесс установки Online Issuing Enterprise Subordinate CA, который так же выполняет роль Policy CA. Теперь нам осталось осталось сконфигурировать этот центр сертификации и параметры в Active Directory. По аналогии с конфигурированием Offline Root CA мы будем использовать post-installation script.
Step 1 — developing post-installation script
:: Создаём папку в корне диска C, где будут храниться CRT и CRL файлы
md C:\CertData::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: конфигурирование параметров CA ::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_PICA%%8%%9.crl\n6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_PICA%%4.crt\n32:http://www.{adatum.com}/ocsp":: Поскольку мы не можем управлять публикацией CRT файлов, мы его
:: переименовываем в нужное имя и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt {Adatum}_PICA.crt
copy %windir%\system32\CertSrv\CertEnroll\{Adatum}_PICA.crt C:\CertData:: задаём максимальный срок действия издаваемых сертификатов равным 5 лет
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years":: Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)
certutil -setreg CA\CRLPeriodUnits 5
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 1:: Включаем наследование Issuer Statement в издаваемых сертификатах
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32":: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
:: Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: конфигурирование параметров AD ::
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: задаём контекст конфигурации для сервера CA. Контекст конфигурации
:: должен указывать на *корневой домен* текущего леса.
certutil -setreg CA\DSConfig "CN=Configuration,DC={adatum},DC={com}":: публикуем сертификат CA в AD
certutil -dspublish -f C:\CertData\{Adatum}_PICA.crt Subca
certutil -dspublish -f C:\CertData\{Adatum}_PICA.crt NTAuthCAnet stop certsvc && net start certsvc
:: Публикуем новый CRL в новую локацию.
certutil –CRL
Примечание: как и раньше, вы должны заменить на свои значения всё, что помещено в фигурные скбоки {}.
Step 2 — Configuring Web Server
Как вы знаете, у нас будут использоваться HTTP ссылки для скачивания файлов CRT/CRL. Для этого нужно настроить соответствующим образом ваш корпоративный веб-сервер. А именно, создать виртуальную директорию (внутри сайта с заголовком www.adatum.com) и в качестве физического пути указать на папку C:\CertData.
Примечание: если ваш веб-сервер работает под управлением IIS 7 и выше, убедитесь, что сервер настроен на двойной эскейпинг для корректного восприятия знака плюс (+) в ссылках. DoubleEscaping можно включить руководствуясь этой ссылкой: Configure Request Filters in IIS 7.
Step 3 — Setup OCSP Responder
В нашем сценарии предполагается, что мы будем использовать OCSP Responder для Issuing CA и, опционально, для Root CA. OCSP Responder для Issuing CA настраивается следующим образом:
Примечание: пост-установочный скрипт уже сконфигурировал расширение AIA включив ссылку на OCSP. Следовательно, настройку этого расширения на сервере CA можно опустить.
Когда OCSP для Issuing CA будет сконфигурирован, можно дополнительно сконфигурировать его и для Root CA (при условии, что корневой CA настроен на публикацию ссылок OCSP в издаваемых сертификатах. Об этом см. секцию Step 3 статьи Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA).
Если в post-installation скрипте вы указали ссылку на OCSP, сертификат Issuing CA её должен содержать в расширении Authority Information Access. Для обеспечения работоспособности этой ссылки необходимо создать ещё одну конфигурацию в OCSP. Для этого выполните следующее:
- Откройте оснастку Online Responder из папки Administrative Tools.
- Выделите Revocation configuration и в меню Action выберите Add Revocation Configuration.
- Откроется мастер создания конфигурации отзыва. Ознакомьтесь с предстоящими шагами и нажмите Next.
- Укажите имя новой конфигурации. Например: RootCA 1. Единичка будет означать номер ключа CA для которого настроена конфигурация. Дело в том, что при каждом обновлении сертификата CA с новой ключевой парой вам необходимо будет создавать новую конфигурацию в OCSP. Нажмите Next.
- На странице Select CA Certificate Location выберите Import certificate from a file и нажмите Next.
- На следующей странице укажите путь к файлу сертификата корневого CA и нажмите Next.
- На странице Select Signing Certificate укажите Manually select signing certificate и нажмите Next.
- На странице Revocation Provider вы можете получить сообщение об ошибке, которая сообщает о том, что мастер не смог получить сведения о конфигурации CA. Это связано с тем, что наш Offline Root CA не подключен к сети и вообще находится в сейфе. Поэтому нажмите кнопку Provider и укажите ссылку на CRL корневого центра сертификации. По условиям нашего сценария, ссылка будет иметь следующий вид:
http://www.adatum.com/pki/Adatum_RCA.crl
Поскольку корневой CA не использует Delta CRL, оставьте это поле пустым. Так же вы можете настроить периодичность, с которой OCSP будет освежать свой внутренний кеш. Например, можно указать каждые 10 минут. Нажмите Ok и вернитесь в мастер создания конфигурации OCSP. - Нажмите Finish для завершения работы мастера.
Вы вернётесь обратно в оснастку OCSP Responder и увидите, что наша созданная конфигурация выдаёт ошибку, поскольку нет сертификата подписи, который будет использоваться для подписи ответов OCSP. Для устранения этого недостатка, разверните секцию Array Configuration и выделите нужный респондер (предполагается, что это тот же самый сервер, на котором вы настраиваете OCSP). В центральной панели выберите конфигурацию RootCA 1 и в панели Actions нажмите на Assign Signing Certificate. Откроется список пригодных сертификатов. Скорее всего он там будет один. Поэтому выберите его и нажмите Ok.
Теперь выделите Array Configuration и в меню Action нажмите Refresh Revocation Data. И вот что вы должны увидеть в конечном итоге:
Results
Для окончательной проверки мы можем запустить оснастку PKIView.msc. Если мы настроили всё правильно, то должны увидеть примерно такой вид:
И подведём итоги того, что мы сделали:
- Мы спланировали типовую 2-х уровневую иерархию и конфигурацию PKI, которая включает в себя Offline Root CA и Online Issuing CA;
- Установили и сконфигурировали соответствующим образом наш корневой Root CA, который может быть нормально выключен и который будет издавать сертификаты только для других центров сертификации;
- Установили и сконфигурировали подчинённый Issuing CA, который будет издавать сертификаты уже конечным потребителям.
- Настроили OCSP Responder для работы с Offline Root CA.
Вроде бы выглядит немного, но исходя из материала мы проделали достаточно большой объём работы, в результате мы получили достаточно гибку и, главное, работающую PKI.
(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)
Большое спасибо за Вашу работу. Нашел одну очепятку, и прошу ее исправить в коде постинстал скрипта certutil -setreg\CA\DSConfig "CN=Configuration,DC={adatum},DC={com}" Перед CA\DSConfig не нужен "\" Спасибо
:: задаём максимальный срок действия издаваемых сертификатов равным 3 года certutil -setreg CA\ValidityPeriodUnits 5 certutil -setreg CA\ValidityPeriod "Years" опечатка в коменте
исправил ошибки в посте.
У меня несколько вопросов-предложений по ходу возникло: 1. в скрипте, что внизу статьи ошибки, указанные предыдущими читателями остались. 2. в скрипте указана команда на останов службы, но мы ее еще не запускали, в связи с рекомендациями ранней статьи. 3. на сервер Вы не рекомендовали ставить IIS, но в тоже время при установке OCSP Responder (она, кстати не ставиться по умолчанию, как указано, а ставиться отдельно в win2008r2) IIS требуется ему.
1) файл я исправлю чуть позже. 2) она запускается сразу после установки сертификата. Следовательно, службу нужно устанавливать 3) а я не говорил, что OCSP должен быть на том же сервере, что и сам CA. Это просто в моём конкретном примере обе роли были установлены на один сервер (лишних виртуалок не было).
Еще 3 вопроса: 1. В статье http://www.sysadmins.lv/PermaLink,guid,dd355e23-ba68-4ff5-a89b-26e7ff2fc089.aspx показано, на fig.4 что сертификат должен содержать AIA, я сделал все по статьям 1-4. Такой записи нет в сертификате. Это правильно или где-то надо испраить? 2. В pkiview.msc на втором уровне с Issuing SubSA сообщение, о том, что не может скачать http://www.pf.loc/pki/PF_PICA.crl хотя файл есть, остальные скачал нормально. В чем может быть дело? 3. В pkiview.msc на первом уровне с Root CA сообщение, о том, что не может скачать ни http://www.pf.loc/pki/PF_RCA%8.crl ни http://www.pf.loc/pki/PF_RCA%4.crt хотя файлы есть. В чем может быть дело?
1) видимо, пропустили это: http://www.sysadmins.lv/PermaLink,guid,8d874040-7f98-4539-ab0e-8af4146ae94b.aspx 2) можете ещё раз убедиться в доступности этих файлов через проверку сертификата. Т.е. взять любой сертификат изданный этим CA (CA Exchange самое популярное), сохранить в файл и выполинить 'certutil -url path\file.cer' и убедиться, что там в CDP везде стоят Verified. Быть может оснастка просто вываливается по таймауту. Ссылка вручную работает? 3) http://www.pf.loc/pki/PF_RCA%4.crt — странный адрес. Что там делает '%4'?
1. Нет тут я все проделал (возможно не явно описано:)), то, что показанано fig. 3 (установка AIA) уже было в сертификате, ведь там сказано: "Для этого вызываем свойства самого CA и переходим на вкладку Extensions:" в остнастке Certification Authority адрес http:// уже был. 2. Пишет для CDP: Status: Expected Base CRL Type: Delta CRL(02) 3. Я так понял %8 отсюда: "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" А %4, отсюда: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt"
Сами файлы по ссылкам из браузера открываются. Файлы с %4 и %8 - нет.
Именно в выдаваемых RootCA сертификатах, вот такое дело: [1]Authority Info Access Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative Name: URL=http://www.pf.loc/pki/PF_RCA%4.crt
"2) она запускается сразу после установки сертификата. Следовательно, службу нужно устанавливать" Нет, не запускается - win2008r2 Ent, проверте сами.
ВАЖНО!!! Читать всем - в скрипте запуска, если команды выполняются из cmd, не нужно ставить %% (два знака процента), нужно ставить один: C:\Users\administrator.PF>certutil -setreg CA\CRLPublicationURLs "65:%windir%\sy stem32\CertSrv\CertEnroll\%3%8%9.crl\n65:C:\CertData\PF_PICA%8.crl\n6:http://www .pf.loc/pki/pf.loc_PICA%8%9.crl" SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\PF SubCA\CRLPublicationU RLs: 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: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 CSURL_SERVERPUBLISH -- 1 CSURL_ADDTOCERTCDP -- 2 CSURL_ADDTOFRESHESTCRL -- 4 CSURL_ADDTOCRLCDP -- 8 CSURL_SERVERPUBLISHDELTA -- 40 (64) 2: 0:http://%1/CertEnroll/%3%8%9.crl 3: 0:file://%1/CertEnroll/%3%8%9.crl 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_PICA%8.crl CSURL_SERVERPUBLISH -- 1 CSURL_SERVERPUBLISHDELTA -- 40 (64) 2: 6:http://www.pf.loc/pki/pf.loc_PICA%8%9.crl CSURL_ADDTOCERTCDP -- 2 CSURL_ADDTOFRESHESTCRL -- 4 CertUtil: -setreg command completed successfully. The CertSvc service may need to be restarted for changes to take effect. C:\Users\administrator.PF>
Смущает следующее, при переустановке СА и выполнении: C:\Users\administrator.PF>certutil -dspublish -f C:\CertData\PF_PICA.crt Subca ldap:///CN=PF SubCA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,D C=pf,DC=loc?cACertificate Certificate already in DS store. CertUtil: -dsPublish command completed successfully. Пишет, что уже есть, как проверить, что за счет члюча -f действительно перезаписался новым сертификатом?
Что касается процентов, удивительно, что вы этого не знали. Ведь проценты в CMD используются для обозначения переменных. В принципе, последняя команда немного избыточна. При публикации любого сертификата в AD через 'certutil -dspublish', его копия помещается в контейнер AIA. Т.е. по большому счёту выполнять 'certutil -dspublish -f file.cer SubCA' не обязательно. Но лишний раз не помешает. На счёт посмотреть, можно и через certutil: certutil -viewstore "ldap:///CN=PF SubCA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,D C=pf,DC=loc?cACertificate" как-то так. Но лучше через оснастку PKIView.msc
"Что касается процентов, удивительно, что вы этого не знали" - не понятно, вы предложили cmd скрипт, с 2-мя процентами. Я думаю нужно внести некоторые правки по ходу статьи :) осталось все же последнее: Не скачивается в pkiview.msc Adatum_PICA.crl. Из браузера по ссылке - доступен.
Цитата: "Особо пытливые умы должны заметить, что в таблице указан один знак процента, а в скрипте по два знака. Никакой магии здесь нет, просто парсер CMD использует проценты для других целей. Следовательно, чтобы парсер CMD его не удалил, знак процента необходимо заэскейпить другим знаком процента." CMD не удаляет %, вот собственно, это стоит совсем убрать, как и второй знак %.
И Вадим, исправьте: certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_PICA%%8.crl\n6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl" Должно быть: certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%3%8%9.crl\n65:C:\CertData\{Adatum}_PICA%8%9.crl\n6:http://www.{adatum.com}/pki/{Adatum}_PICA%8%9.crl" Т.е. нет %9 в середине.
> не понятно, вы предложили cmd скрипт, с 2-мя процентами а что именно непонятно? > CMD не удаляет % при запуске из скрипта, проценты вырезает сам certutil.
вот, кстати, пруф: This behavior occurs if you use replacement tokens in the Certificate Services MMC or if you use them in a certutil command. If replacement tokens are used in a batch file, and you use the percent sign (%), you must use another escape sign when needed, because the Windows shell typically interprets a percent sign as a command-line parameter. http://technet.microsoft.com/en-us/library/cc784969(WS.10).aspx
Не понял часть поста о том, как создаем Revocation Configuration RootCA 1 - в конце вручную указываем сертификат для подписи ответов Online responder. Откуда там должен взяться указанный сертификат"? Насколько понимаю, нужно получить сертификат, изданный RootCA по шаблону "OCSP Response Signing"?
Как мы знаем, RootCA у нас Standalone и не поддерживает шаблоны. Технически можно использовать один сертификат подписи для всех конфигураций (это описано в этом блог-посте), хотя это совсем не бест-практис. В идеале каждый CA должен выдавать сертификат подписи для своей конфигурации OCSP. Другое дело, что с Offline CA дело будет немножечко сложнее. Поскольку Offline CA большую часть выключены, они не могут часто (даже каждые 2 недели), а т.к. они Standalone — они не могут это делать автоматически. Следовательно, для Offline CA, срок действия сертификата подписи будет составлять примерно 1-2 года. Учитывая особенности сертификатов OCSP Signing, придётся либо устанавливать HSM на OCSP респондер или отказываться от OCSP для Offline CA. Я намеренно пропустил эту часть, поскольку считаю, что это будет излишним на данном этапе.
По ходу статьи мы нигде не публикуем в AD сертификат offline root CA. Как это лучше сделать - через certutil -dspublish или используя групповые политики?
Лучше всего через certutil -dspublish -f filename.crt RootCA Дело в том, что этот контейнер, куда публикуется сертификат) реплицируется между всеми контроллерами всего *леса*, а не домена. Единственное исключение. Если вы хотите распространить EV сертификат (с преднастроенным OID в свойствах корневого сертификата), его нужно будет распространять через групповые политики. Это связано с тем, что только интерфейс групповых политик поддерживает распространение сертификатов со свойствами. Публикация в AD не имеет такой возможности.
Вадим, подскажите, пожалуйста. После установки всего точно по Вашей инструкции CA стал выдавать сертификаты с алгоритмом подписи RSASSA_PSS. И этот сертификат не воспринимается Windows XP. Как я понимаю это из за параметра AlternateSignatureAlgorithm = 1 ?
Да. Я в другой статье сделал сноску про несовместимость AlternateSignatureAlgorithm с Windows XP/2003, а тут забыл просто.
1. В файле для загрузки: certutil -setreg CA\CRLPublicationURLs ... 2:http://www.adatum.com/pki/Adatum_PICA%%8%%9.crl В посте: certutil -setreg CA\CRLPublicationURLs ... 6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl 2. certutil -setreg CA\CACertPublicationURLs ... 6:http://www.adatum.com/pki/Adatum_PICA%%4.crt certutil -setreg CA\CACertPublicationURLs ... 2:http://www.{adatum.com}/pki/{Adatum}_PICA%%4.crt Как правильно?
Правильно будет заменить все упоминания adatum и всё, что в фигурных скобках — {} (сами скобки не нужны) надо заменить на свои значения. Упомянутые ссылки предполагают, что они относятся к Adatum PKI.
Извиняюсь за не корректно заданный вопрос. Со скобками все ясно. Интересуют цифры перед :http
Извиняюсь за некорректно заданный вопрос. Со скобками все ясно. Интересуют цифры перед :http
а циферки расписаны здесь: http://www.sysadmins.lv/PermaLink,guid,7cddb78e-fece-4d8a-8c85-813055311492.aspx
Здравствуйте Вадим! Проделал вроде все как написано, но получил одну ошибку. Мой домен testdom.local (w2k8r2). В Enterprise PKI>TESTDOM Class 1 RCA (v0.0)>TESTDOM Class1 Issuiring SubCA - все тесты OK. А в Enterprise PKI>TESTDOM Class 1 RCA (v0.0) -- OCSP Location #1 выдает Error, хотя и там и там ссылка на сервис ocsp одна и та же: http://www.testdom.local/ocsp. В чем может быть причина?
А сам OCSP Responder настроили?
Да. OCSP Показывает зеленую галочку и working. при попытке настроить его для RootCA писал Bad signing certificate on Array Controller. пока удалил эту revocation configuration
Вроде заработало :) Но для RootCA 1 назначил Manual assignment - выбрал 1 единственный предлагаемый сертификат домена - других вариантов не было. Правильно ли это?
Здравствуйте Вадим! Я пробую настраивать это все в рабочей конфигурации, но неожиданно при попытке назначить сертификат для RootCA при настройке Online Responder выдает что нет доступных сертификатов (no certificate available). Все удалил переделал заново - то же самое. Не могу понять где ошибся. Подскажите где искать?
> выбрал 1 единственный предлагаемый сертификат домена - других вариантов не было. Правильно ли это? в принципе, да, ничего страшного в этом нету. кстати, после ручного обновления/назначения сертификатов и вообще изменения конфигураций, рекомендуется обновлять конфигурацию. Правой кнопкой на Array Configuration и там Refresh Revocation data. Очень помогает.
Доброго всем времени суток. Вадимс, позвольте одно замечание и ряд вопросов (куда же без них :)). 1. Один посетитель вашего блога уже замечал эту очепятку, но оказался ненастойчивым - вроде бы действительно есть несоответствие приложенного скрипта шага 1 и его содержимым на web-странице - на странице правильно в скрипте вроде нет. Для CA\CRLPublicationURLs - правильно "6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl", для CA\CACertPublicationURLs - "2:http://www.{adatum.com}/pki/{Adatum}_PICA%%4.crt", в скрипте параметры публикации 6 и 2 расположены наоборот. 2. Хоть вы его - LDAP - и не любите в путях CDP и AIA :), но всё же естественно им занимались. Поэтому скажите, плз, если мы всё же его хотим использовать в путях для размещения и проверки сертификатов и CRL'ей, то судя по тому что написано в комментариях в ветке по установке ROOTCA и ссылке http://technet.microsoft.com/en-us/library/cc737740%28WS.10%29.aspx нужно, помимо уже написанного, на ROOTCA (до выпуска сертификата subca!) выполнить команды: certutil -setreg CA\DSConfig "CN=Configuration,DC=Adatum,DC=COM" certutil -setreg CA\DSConfigDN "CN=Configuration,DC=Adatum,DC=COM" certutil -setreg CA\DSDomainDN "DC=Adatum,DC=COM" ? Этого достаточно или нужно что-то убрать/довыполнить? Также не нужно ли в скрипте шага 1 текущей ветки выполнять также команды и для контекстов конфигураций "CA\DSConfigDN" и "CA\DSDomainDN"? (или это было нужно для w2003?) 3. Если мы будем испльзовать пути проверки сертификатов через LDAP, то надо ли (можно ли) помимо сертификата RootCA (certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA) внести аналогичным образом CRL RootCA в LDAP? Какова будет для этого команда? 4. Да, и кстати ещё вопрос - если мы даже не используем LDAP в путях сертификатов, мы вносим в LDAP сертификаты rootca и subca для того, чтобы они автоматически добавлялись в контейнеры на хостах, вводимых в домен или ещё для чего-то? Спасибо за ваш труд...
Здравствуйте В чем-то присоедеюсь к предыдущему комментатору. Не считаете ли вы более правильным публиковать сертификаты в AD? Ведь, при этом не обязательно давать этот пусть как расширение к сертификату, т.е. дать ему разрешение - 1 (Publish CRLs to this location) Ведь в этом случае и в самом сертификате не появятся пути, которые невозможно проверить снаружи, и сам сертификат будет храниться в AD, что удобно. Тем более, что в шаблоне можно будет этим управлять. Или у вас есть другие соображения, почему не стоит хранить их в AD?
> Для CA\CRLPublicationURLs - правильно "6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl", для CA\CACertPublicationURLs - "2:http://www.{adatum.com}/pki/{Adatum}_PICA%%4.crt", в скрипте параметры публикации 6 и 2 расположены наоборот. нет, тут всё правильно написано. Для CRL'ов флаг будет 6 (для публикации ссылок в издаваемые сертификаты), а для CRT (файла сертификата самого CA) должен быть 2. > Этого достаточно или нужно что-то убрать/довыполнить? этого достаточно. > Если мы будем испльзовать пути проверки сертификатов через LDAP, то надо ли (можно ли) помимо сертификата RootCA (certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA) внести аналогичным образом CRL RootCA в LDAP? Какова будет для этого команда? тогда просто: certutil -dspublish -f file.crl > Да, и кстати ещё вопрос - если мы даже не используем LDAP в путях сертификатов, мы вносим в LDAP сертификаты rootca и subca для того, чтобы они автоматически добавлялись в контейнеры на хостах, вводимых в домен или ещё для чего-то? да. Сертификты CA из Active Directory автоматически устанавливаются в локальное хранилище доменных клиентов. > Не считаете ли вы более правильным публиковать сертификаты в AD? Ведь, при этом не обязательно давать этот пусть как расширение к сертификату, т.е. дать ему разрешение - 1 (Publish CRLs to this location) вы говорите про сертификаты или про CRL'ы?
>> Для CA\CRLPublicationURLs - правильно "6:http://www.{adatum.com}/pki/{Adatum}_PICA%%8%%9.crl", для CA\CACertPublicationURLs - "2:http://www.{adatum.com}/pki/{Adatum}_PICA%%4.crt", в скрипте параметры публикации 6 и 2 расположены наоборот. > нет, тут всё правильно написано. Для CRL'ов флаг будет 6 (для публикации ссылок в издаваемые сертификаты), а для CRT (файла сертификата самого CA) должен быть 2. Извините за назойливость :). Да я ж и не спорю - в теле статьи всё хорошо, неправильно в прикреплённом в конце статьи txt-файле - посмотрите, пожалуйста - в нём перепутано 6 и 2.
исправил в файлике.
>> Не считаете ли вы более правильным публиковать сертификаты в AD? Ведь, при этом не обязательно давать этот пусть как расширение к сертификату, т.е. дать ему >разрешение - 1 (Publish CRLs to this location) >вы говорите про сертификаты или про CRL'ы? Прошу прощения,запутался. Этот вопрос снят. Зато есть другой. У вас есть готовая процедура, а может и скрипт обновления сертификата корневого и выдающего CA? Процедура это редкая, но тем не менее.
Нету. Но можете написать и самостоятельно.
Здравствуйте Вадимс Еще один короткий вопрос. Как и c помощью можно посмотреть/достать/удалить сертификаты из AD? Сертификаты пользователя видны в расширенном режиме AD Users and Computers. Но компьютерных там посмотреть нельзя.
А компьютерные не публикуются в AD, если вы о них.
>А компьютерные не публикуются в AD, если вы о них. Т.е. галка о публикации в AD для шаблона действует только на сертификаты пользователей? Остальные хранятся только на компьютере с выдающим CA?
остальные хранятся только на целевых компьютерах.
Вадим, почему-то не могу настроить OCSP. "Вы вернётесь обратно в оснастку OCSP Responder и увидите, что наша созданная конфигурация выдаёт ошибку, поскольку нет сертификата подписи, который будет использоваться для подписи ответов OCSP. Для устранения этого недостатка, разверните секцию Array Configuration и выделите нужный респондер (предполагается, что это тот же самый сервер, на котором вы настраиваете OCSP). В центральной панели выберите конфигурацию RootCA 1 и в панели Actions нажмите на Assign Signing Certificate. Откроется список пригодных сертификатов. Скорее всего он там будет один. Поэтому выберите его и нажмите Ok." В момент выбора сертификата у меня не отображается ни один сертификат. Они должны быть установлены на серверную машину, хотя они итак стоят. Проверил все, разобраться до сих пор не могу. Пока на время просто отключил OCSP в точках распространения AIA. Подскажите, пожалуйста, в чем может быть причина? P.S. Вадим, огромное вам спасибо за данный блог, каждая статья новая информация для размышления и оптимизации PKI в организации.
Навскидку могу придумать, что вы службе Network Service не дали прав чтения закрытого ключа.
Вадим, хочу задать еще вопрос - после успешного выполнения всех действий, после отзыва сертификата его проверка так и не происходит он до сих пор пишет что он действителен. Работа с командами не принесла успеха. certutil -setreg chain\ChainCacheResyncFiletime @now certutil –delreg chain\ChainCacheResyncFiletime Что можно в этом случае попробовать. Спасибо заранее! P.S. если вытаскивать информацию из сертификата, то точка распространения там указана, и можно загрузить CRL. Строка следующего характера: URL=http://dir47.domain.test.ot/pki/Adatum_PICA.crl.
надо немного подождать.
:: задаём максимальный срок действия издаваемых сертификатов равным 5 лет certutil -setreg CA\ValidityPeriodUnits 5 certutil -setreg CA\ValidityPeriod "Years" restart certutil -getreg CA\ValidityPeriodUnits ValidityPeriodUnits REG_DWORD = 5 а сертификаты пользовательские и компьютерные почему-то всё равно выдаёт на 1 год, запрашивал через консоль и через вэб.
Потому что в шаблоне стоит 1 год.
ок, тогда для чего это нужно :: задаём максимальный срок действия издаваемых сертификатов равным 5 лет certutil -setreg CA\ValidityPeriodUnits 5 certutil -setreg CA\ValidityPeriod "Years" то есть я в шаблоне не смогу более 5 лет выставить, и если создать копию шаблона со старым шаблоном что делать?
Это нужно, чтобы задать настройку на уровне сервера. Если вы в шаблоне поставите 10 лет, то выиграет меньшее значение, т.е. будет только 5 лет. Если в шаблоне 2 года, выиграет меньшее значение — 2 года. а со старым шаблоном ничего делать не надо.
C:\Users\Администратор>certutil Запись 0: (локальный) Имя: `testdom2CA' Подразделение: `' Организация: `' Размещение: `' Область: `' Страна или регион: `' Настройка: `msrv2.testdom2.net\testdom2CA' Сертификат обмена: `' Сертификат подписи: `msrv2.testdom2.net_testdom2CA.crt' Описание: `' Сервер: `msrv2.testdom2.net' Центр: `testdom2CA' Исключенное имя: `testdom2CA' Краткое имя: `testdom2CA' Исключенное краткое имя: `testdom2CA' Флаги: `13' Серверы регистрации через Интернет: `' CertUtil: -dump - команда успешно выполнена. а как заполнить не заполненные строки?
Заполнить их в Active Directory. Подобные вопросы вам следует задавать на форумах технет.
Comments: