Update 03.04.2010: добавлен OID для PolicyStatementExtension.
Update 26.06.2011: добавлена публикация корневого сертификата в Active Directory.
Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf. Обязательно прочтите.
Ссылки на другие материалы из этой серии:
В предыдущей части мы подготовили, установили и настроили наш первый корневой центр сертификации. Теперь настала пора подготовить, установить и настроить издающий центр сертификации, называемый Issuing CA. Так же, Issuing CA будет совмещать роль Policy CA.
Несколько слов о роли Policy CA. Технически Policy CA выражается расширением Certificate Policies в сертификате CA. Данное расширение содержит ссылку на страницу загрузки CPS (Certificate Practice Statement). CPS — юридический документ, регламентирующий работу центров сертификации компании, включающий в себя наиболее важные части:
- Описание организации иерархии PKI, её состав и меры защиты, принятые для обеспечения физической безопасности серверов CA;
- Уровни ответственности и assurance для издаваемых сертификатов.
- Описание процедуры подачи заявки на сертификат. Этот пункт включает описание мероприятий, применяемых для идентификации реквестора (кто запрашивает сертификат), методы подачи заявки (автоэнроллмент, Web Enrollment Pages, отправка по электронной почте и др.);
- Описание процедуры отзыва сертификатов. Этот пункт включает порядок получения заявки на отзыв, идентификация реквестора, порядок отзыва сертификатов и порядок публикации CRL;
- Описание процедур при решении организационных и технических вопросов.
В реальном мире CPS является очень важным документом, регламентирующим всю работу PKI. Данный документ должен быть доступен для каждого потребителя сертификатов вашей PKI и он является поводом для доверия или недоверия к вашей PKI. Несоблюдение правил описанных в CPS со стороны владельца PKI фактически означает аннулирование доверия вашей PKI. Так же в реальном мире, вам придётся пройти аудит в случае кросс-сертификации с другой иерархией PKI.
Примечание: кросс-сертификация (cross-certification) является процедурой и механизмом доверия одной компанией PKI другой компании. Вопросы кросс-сертификации выходят за рамки рассматриваемого материала.
Каждой уважающей себя компании использующей PKI необходимо иметь такой документ. Для облегчения процесса написания CPS вы можете воспользоваться рекомендациями RFC 3647: http://tools.ietf.org/html/rfc3647, а так же посмотреть аналогичные документы коммерческих CA (например: https://www.verisign.com/repository/cps/index.html) и переложить их под свои условия.
В данном посте я не буду обсуждать вопросы CPS, а только покажу как информация о CPS прикрепляется к сертификату CA. Однако, хочу заметить, что для использования CPS, вы ему должны назначить свой OID, который принадлежит вашей компании. Более подробно об OID'ах здесь: Что в OID'е тебе моём?
Step 1 — Preparing Subordinate Issuing CA
Предполагается, что компьютер с именем IssuingCA установлен, обновлён и сконфигурированы параметры безопасности. Данный компьютер является членом домена Active Directory с именем Adatum.com. Данный компьютер будет выполнять роль издающего центра сертификации (Issuing Certification Authority) с совмещением роли Policy CA. Данный центр сертификации будет постоянно подключен к сети и обслуживать заявки на сертификаты от непосредственных потребителей.
Вводные данные для издающего сервера CA:
- Имя CA — Adatum Class 1 Issuing SubCA 1;
- Тип CA — Subordinate Enterprise.
- Срок действия сертификата CA — 10 лет;
- Срок действия издаваемых сертификатов — не более 5 лет;
- Срок действия Base CRL — 5 дней ;
- Срок действия Delta CRL — 12 часов;
- Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с: Планирование расширений CDP и AIA;
- CDP и AIA будут использовать только ссылки на HTTP. LDAP использоваться не будет.
- OCSP для Issuing CA предусмотрен.
Step 2 — Installing AD CS role on Subordinate Issuing CA
Примечание: все операции выполняемые на сервере, который будет держать роль Issuing CA необходимо выполнять с правами Enterprise Admins.
Перед установкой роли AD CS, необходимо создать конфигурационный файл, который будет использоваться установщиком роли. Для этого в папке %systemroot% необходимо создать файл с именем CAPolicy.inf и внести в него следующий текст:
[Version]
Signature = "$Windows NT$"[PolicyStatementExtension]
Policies = {Adatum}CPS[{Adatum}CPS]
URL = http://www.{adatum.com}/pki/policies.html
OID = 2.5.29.32.0[certsrv_server]
; Устанавливаем длину ключа, которая будет использоваться
; *только* при обновлении сертификата CA
RenewalKeyLength = 2048
; Устанавливаем срок действия обновлённого сертификата.
; Будет использоваться *только* при обновлении сертификата CA
RenewalValidityPeriodUnits = 10
; Устанавливаем единицу измерения для предыдущего параметра
RenewalValidityPeriod = years
; Устанавливаем периодичность публикации CRL в 5 дней
CRLPeriodUnits = 5
CRLPeriod = days
; Устанавливаем срок продления CRL. Фактический срок действия CRL для клиентов увеличивается на
; на заданный период, который в нашем случае равен 2 неделям. Это означает, что сервер CA будет
; публиковать новый CRL каждые 90 дней, а срок действия этого CRL будет 104 дня. Это даст
; администраторам возможность успеть забрать новый CRL с сервера и распространить его в нужные локации
CRLOverlapUnits = 1
CRLOverlapPeriod = days
; Устанавливаем периодичность публикации CRL в 12 часов
CRLDeltaPeriodUnits = 12
CRLDeltaPeriod = hours:: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: 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 укажите название вашей компании. Места, в которых необходимо прописать свои данные заключены в фигурные скобки — {}.
- На странице Before You Begin вы можете ознакомиться с информацией об этом мастере. После ознакомления нажмите Next.
- На странице Select Roles выберите Active Directory Certificate Services и нажмите Next.
- На следующей странице прочтите вводную информацию о роли AD CS и нажмите Next.
- На странице Role Services убедитесь что установлен чек-бокс только напротив Certification Authority и нажмите Next.
- На странице Setup Type выберите Enterprise и нажмите Next.
- На странице выбора типа CA выберите Subordinate CA и нажмите Next.
- На странице Private Key выберите Create a new private key и нажмите Next.
- На странице Cryptography выберите следующий криптопровайдер из списка: RSA#Microsoft Software Key Storage Provider
Установите длину ключа в 2048 бит и алгоритм подписи в SHA1. После чего нажмите Next. - На странице выбора имени CA введите следующее:
{Adatum} Class 1 Issuing SubCA 1.
в поле Distinguished name suffix укажите примерно такое:
OU=Information Systems,O={Adatum Ltd.},C={LV}
и нажмите Next. - На странице Certificate Request установите переключатель на Save certificate request и укажите путь размещения файла запроса. Поскольку наш корневой CA недоступен из домена, мы сохраним файл запроса и отправим его на корневой сервер. Нажмите Next.
- На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
- На странице Confirmation просмотрите настройки, которые вы указали. Если вы ошиблись на каком-то этапе — вернитесь назад и исправьте ошибку. Если всё правильно, нажмите Install и подождите пока мастер сконфигурирует роль.
- На странице Results ознакомьтесь с результатами установки и необходимыми шагами для завершения установки. Закройте мастер кнопкой Close.
Step 3 — Completing Subordinate Issuing CA installation
На этапе установки Issuing CA у нас сгенерировался файл запроса, который нужно отправить на наш корневой центр сертификации, чтобы тот его подписал и выдал нам рабочий сертификат. Поэтому скопируйте файл запроса (должен быть сохранён по пути указанному в пункте 10) на съёмный носитель и перенесите его на корневой CA. На корневом CA выполните следующие шаги:
- Запустите оснастку Certification Authority из папки Administrative Tools.
- Выделите секцию с именем CA, нажмите Action –> All Tasks –> Submit new request.
- В диалоговом окне укажите файл запроса, который был сгенерирован на этапе установки Issuing CA.
- Теперь запрос находится в очереди ожидания.
- Перейдите в секцию Pending Requests, выделите нужный запрос (он там скорее всего будет единственный), нажмите правой кнопкой и нажмите Issue.
- Должно появиться диалоговое окно сохранения файла сертификата. Сохраните сертификат в папке C:\CertData.
- Если диалоговое окно автоматически не появилось, перейдите в секцию Issued certificates, откройте сертификат, перейдите на вкладку Details и там нажмите кнопку Copy to file. Сохраните файл в папку C:\CertData.
- Скопируйте всё содержимое папки C:\CertData на съёмный носитель.
- Выйдите из системы или выключите сервер. На данном этапе в следующий раз наш Offline Root CA потребуется включить через 3 месяца для публикации нового CRL или когда потребуется отправить ещё один запрос или отозвать какой-то сертификат.
Вернитесь на Issuing CA для завершения инсталляции.
- Скопируйте файлы со съёмного носителя (содержимое папки CertData, которое вы скопировали на предыдущем этапе) на локальный диск. Например, в ту же папку C:\CertData.
- Запустите консоль CMD с расширенными привилегиями (elevated mode) и выполните в ней следующие команды:
certutil –addstore Root C:\CertData\Adatum_RCA.crt
certutil –addstore Root C:\CertData\Adatum_RCA.crl
certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA
где Adatum_RCA.crt — файл сертификата корневого центра сертификации. Его нужно установить для обеспечения доверия этому и другим сертификатам в его цепочке.
где Adatum_RCA.crl — файл списка отзыва корневого центра сертификации. Его нужно установить для обеспечения возможности проверки сертификатов на отзыв. В противном случае при установке Issuing CA, он не сможет проверить на отзыв свой собственный сертификат. - Убедитесь, что ошибок не произошло. Если это так, закройте консоль CMD.
Теперь можно установить сертификат на сервер CA. Для этого запустите оснастку Certification Authority из папки Administrative Tools. В оснастке выделите имя центра сертификации, нажмите Action –> All tasks –> Install CA certificate. В диалоговом окне перейдите на папку C:\CertData и укажите файл SubCA1.cer и нажмите Open. Если импорт прошёл без ошибок, сертификат CA был установлен успешно. Но запускать службу Certificate Services ещё рано.
Нам осталось написать и выполнить послеустановочный скрипт, который сконфигурирует сервер CA и подготовит AD к успешной работе. Но об этом в следующий раз.
(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)
>>Данный компьютер будет выполнять роль издающего центра сертификации (_Root Certification Authority_) с совмещением роли Policy CA. что-то тут не верно, не находите ? ;-)
ага. Издержки копипасты.
При выполнении данных рекомендаций на шаге: 2. Выделите секцию с именем CA, нажмите Action –> All Tasks –> Submit new request. Получаем: Error Parsing Request The request subject name is invalid or too long. 0x80094001 (-2146877439)
а что показывает 'Certutil -dump requestfile.req'?
c:\>certutil -dump 1.req PKCS10 Certificate Request: Version: 1 Subject: CN=PF Class 1 Issuing SubCA 1 OU=Information Systems O=PF C=loc Public Key Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA Algorithm Parameters: 05 00 Public Key Length: 2048 bits Public Key: UnusedBits = 0 0000 30 82 01 0a 02 82 01 01 00 c9 82 55 fd c5 84 36 0010 d1 37 2b bd a3 ea 2b ee 1f 1c 15 30 aa 49 80 ff 0020 70 2a 34 2e 3c f3 b6 2c c7 08 96 a7 88 51 ae 8b 0030 1f 6d 09 94 1e 56 cc 99 aa d7 49 1c 9e d9 28 52 0040 11 c1 35 26 8e 5d 46 84 a1 9a 93 46 33 bb 42 8e 0050 80 46 c2 45 3b 77 dc e7 28 00 51 44 34 df e2 1d 0060 02 e6 a4 26 75 d1 25 70 7f fd 37 3b c5 3c 11 e4 0070 68 a0 8b 9e 8f 5a 1a 76 ad 04 b2 4e d5 77 8b 1a 0080 0c 30 c6 04 32 a8 8d 20 5a 01 8f 68 80 8e a7 b3 0090 04 93 70 76 f6 7a d4 77 30 f2 55 9a 6c 7a 56 40 00a0 f3 6a 19 13 f5 32 1b cc a3 de 4c 3f 17 99 6b 08 00b0 a8 cc 8f 05 6e 47 25 f7 cb 65 21 78 d3 a3 ea 52 00c0 5a e4 f5 d5 ea 3f 6a 97 9c a9 29 2c 69 ad e2 d0 00d0 ca 01 c4 fd 60 0b 3f bf 45 f7 94 37 e3 03 33 9f 00e0 1b fa 99 53 e6 d8 ef 3b 79 3f eb ca 77 ee 41 73 00f0 c4 a7 76 1f f4 b8 a1 61 dd 3d 73 51 df 02 69 5b 0100 4e 0f 4c 6d c9 c4 0f 99 3d 02 03 01 00 01 Request Attributes: 2 2 attributes: Attribute[0]: 1.3.6.1.4.1.311.13.2.3 (OS Version) Value[0][0]: 6.1.7600.2. Attribute[1]: 1.2.840.113549.1.9.14 (Certificate Extensions) Value[1][0]: Unknown Attribute type Certificate Extensions: 6 1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3 CA Version V0.0 2.5.29.14: Flags = 0, Length = 16 Subject Key Identifier 9f b3 df 44 7c c1 f2 2e 54 ce 2e 24 f0 2e 5a 2a 2e 1d f7 94 2.5.29.32: Flags = 0, Length = 3d Certificate Policies [1]Certificate Policy: Policy Identifier=All issuance policies [1,1]Policy Qualifier Info: Policy Qualifier Id=CPS Qualifier: http://www.pf.loc/pki/policies.html 1.3.6.1.4.1.311.20.2: Flags = 0, Length = c Certificate Template Name (Certificate Type) SubCA 2.5.29.15: Flags = 0, Length = 4 Key Usage Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signin g (86) 2.5.29.19: Flags = 1(Critical), Length = 5 Basic Constraints Subject Type=CA Path Length Constraint=None Signature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA Algorithm Parameters: 05 00 Signature: UnusedBits=0 0000 47 e7 65 b6 0c 7d 5a c1 a0 c2 96 14 2e 60 e2 72 0010 de 9c 71 47 0c 59 8e 81 0e eb 80 94 0b 03 e9 11 0020 a6 34 3a 87 95 5d 4f 39 85 0f 45 1d 3c 95 84 a2 0030 28 e9 e8 70 75 12 56 a7 ba 07 9c 23 28 d1 b3 c4 0040 9c 2c 02 23 1a 15 8a a3 91 05 db 2a c2 a9 f5 41 0050 28 44 78 b8 5e 59 8f a8 21 95 24 a0 47 36 1d c3 0060 2e 05 4f de 1a 58 7b f6 d9 87 f5 9c e6 a9 89 f2 0070 df f3 6e 21 af 00 d7 fc 0b ed 1c 9f 04 12 25 2c 0080 3a 17 c7 00 2d ca dd 2b 1d 68 ca e0 93 dc a6 3a 0090 b7 18 09 a4 65 c8 15 b1 49 f3 86 21 27 e9 e3 b8 00a0 8b 90 b1 48 a0 bd 23 fe ad 22 e1 2e 3e 3d 32 93 00b0 f6 9f cc 2b 78 e0 2c 09 50 96 a5 ce ae 1b 80 35 00c0 14 d4 26 23 3f d6 73 41 15 4c a4 d3 29 7d 4a 41 00d0 bb da 7a 7b f2 07 d7 80 69 fd de a1 f7 71 e2 6c 00e0 b4 5e 59 66 cf 59 d2 a9 0b c5 62 6e e6 ec d3 94 00f0 91 d1 3b cc 91 7b 55 66 f3 b3 76 aa 49 ce 9c 4d Signature matches Public Key Key Id Hash(rfc-sha1): 9f b3 df 44 7c c1 f2 2e 54 ce 2e 24 f0 2e 5a 2a 2e 1d f7 94 Key Id Hash(sha1): 73 f0 0b a2 56 18 e2 12 da f2 9d 8a 61 59 63 fa 5c c2 32 5e CertUtil: -dump command completed successfully.
Eсли я не ошибаюсь, суффикс C (Country) в DN не может быть длиннее 2-х байт. Т.е. надо указать что-то вида: RU/UK/LV.
Если сделать csr.inf с: [NewRequest] Subject="CN=hv-EntCA,dc=pf,dc=loc" То не ругается. Теперь вопрос, как создать csr.inf со всеми правильными параметрами? :)
Проверил, да, Вы правы. Вопрос - как создать повторно правильный запрос? Будет ли как-то влиять на ифраструктуру то, что RootCA всеже с: CN=PF Class 1 Root Certification Authority OU=Information Systems O=PF C=loc
Вы не путайте, C (Country) и DC (Domain Component) — не одно и то же ;) DC позволяет делать длинные суффиксы :) > Вопрос - как создать повторно правильный запрос? удалить роль CA с сервера и установить по новой. Иначе никак. > Будет ли как-то влиять на ифраструктуру то, что RootCA всеже с нет, это просто информативная часть вашего DN'а.
Далее по ходу текста: Запустите консоль CMD с расширенными привилегиями (elevated mode) и выполните в ней следующие команды: certutil –addstore Root C:\CertData\Adatum_RCA.crt certutil –addstore Root C:\CertData\Adatum_RCA.crl Возник вопрос - скрипт для RootCA (из ранней части статьи) создаст файл с имененм Adatum_RCA%8.crl Как тогда будет правильно? certutil –addstore Root C:\CertData\Adatum_RCA.crl или certutil –addstore Root C:\CertData\Adatum_RCA%8.crl
правильно будет вот так: certutil –addstore Root C:\CertData\Adatum_RCA.crl %8 будет заменяться на индекс ключа CA при обновлении сертификата CA. Подробнее тут: http://www.sysadmins.lv/PermaLink,guid,7863aaeb-ca0f-4b51-8406-b9821179edd9.aspx
Здравствуйте, Вадим. Хотел просить...Можно ли использовать разные алгоритмы криптографии на RootCA и IssuingCA? Допустим на RootCA SHA1 на IssuingCA SHA2. Спасибо!
Можно, но это совершенно бессмысленно.
Дело в том, что уже существует центр сертификации с Рутом с SHA1 и надо выдать сертификат другой организации в которой тоже есть свой центр сертификации с IssuingCA SHA2. Т.е хотел узнать не будут ли какие либо конфликты. Спасибо!
проблемы будут только у клиентов не поддерживающие SHA2 — до Windows Vista.
Я опять к Вам. Здравствуйте! Возникла проблема. никак не могу разобраться. По иерархии у меня ISCA копирует дельта CRL-лы каждые 3 часа на LDAP1 и LDAP2 которые в NLB. Раньше всё было наман. в последнее время заметил что ISCA копирует delta CRL тока на LDAP1. заранее в schedule task на каждое из ЛДАП был создан файлик который копировал содержимое фтп с срл-ами на другую машину. т.е лпад1 на лдап 2 и обратно с проверкой времени. пришлось подправить файлик на лдап1 что бы он копировал с него дельта СРЛ на лдап2. в идеале лдап2 должен непосредственно от ISCA получать дельту. в чём может быть проблема? Спасибо!
Прочитал 3 раза, но как-то мысли не уловил, к сожалению.
Вадим, огромное спасио за замечательные статьи! (Вовремя меня сюда с technet отправили). Одно жаль, из-за перекрестных ссылок не сразу все в голове укладывается. Поэтому дурацкий вопрос: никак в толк не возьму, при описанной схеме откуда клиент внутри сети может забрать созданный/обновленный сертификат?
о каком именно сертификате идёт речь?
Собственно сертификате пользователя для аутентификации в домене AD.
А так же сертификаты самих DC и почтового сервера. (вот, забыл про них).
Пользовательские сертификаты доставляются клиентам обычно через автоэнроллмент: http://www.sysadmins.lv/PermaLink,guid,2383def5-47ae-4f87-a94b-cbffad67a7a9.aspx
Спсибо. буду изучать пока что.
Запутался, наставьте на путь истинный :) Усть "корневой standalone", который имеет открытый и закрытый ключи. Устанавливаю "издающий enterprise", при установке которого создаётся открытый и закрытый ключи, которые должны быть подписаны корневым. Также при установке создался файл с запросом к корневому серверу, для подписания. Что в этом файле запроса? (я думал что в нём открытый и закрытый ключи издающего сервера, и какая-то служебная информация, необходимая для их подписания) Далее, на корневом сервере, выполнив "Submit new request", указав файл запроса с издающего сервера, получился какой-то сертификат, я ожидал увидеть подписанные сертификаты издающего сервера. Ну и дальше непонимание пошло накапливаться снежным комом ... Я что-то упускаю в описанной ситуации, подскажите пожалуйста, как в действительности происходит.
> Что в этом файле запроса? в файле находятся данные, необходимые для формирования сертификата. Например, поле Subject, открытый ключ реквестора, атрибуты запроса и расширения (опционально). Запрос подписывается закрытым ключом реквестора и вышестоящий CA проверит подпись при помощи открытого ключа, который находится в файле запроса. Запомните, что в запросе никаких закрытых ключей нету. > получился какой-то сертификат не какой-то, а сертификат подчинённого CA, который вам надо установить. После установки и окончательной настройки, подчинённый сервер готов к работе.
Добрый день. Извеняюсь за свою не внимательность. Но мне интересно для чего это мы прописываем и от куда возьмется policies.html [{Adatum}CPS] URL = http://www.{adatum.com}/pki/policies.html OID = 2.5.29.32.0
Доброго времени суток. Вадимс я правильно понимаю, свой OID мы задаем тут (Если СА только устанавливается) [{Adatum}CPS] URL = http://www.{adatum.com}/pki/policies.html OID = 2.5.29.32.0 ? И еще вопрос в 4 части выполняется команда :: Включаем наследование Issuer Statement в издаваемых сертификатах certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32" Я немного не понял это просто команда на включение SAN или в конце указывается мой реальный OID ?
> Но мне интересно для чего это мы прописываем и от куда возьмется policies.html прописываем затем, чтобы пользователи сертификатов могли бы познакомиться с вашей политикой использования сертификатов. Откуда возьмётся? Его вы должны создать сами. > Я немного не понял это просто команда на включение SAN или в конце указывается мой реальный OID ? а причём тут SAN? Написано же явно, что это наследование расширения Certificate Policies. И здесь указывается OID расширения, т.е. 2.5.29.32.
>а причём тут SAN? Написано же явно, что это наследование расширения Certificate Policies. И здесь указывается OID расширения, т.е. 2.5.29.32. Тоесть с виданным мне OID он ничего общего не имеет и выданный на мою организацию OID прописываеться при создании Issuing CA в CAPolicy.inf ? Прошу прошения за идиотские вопросы. Есть еще вопрос. А будет ли корректно сделать так ? Если мы публикуем ссылки CDP и AIA только на вебсайт и не будем использовать ссылки на LDAP. Внутренних клиентов через алисас в ДНС перенаправлять на опубликованный сайт изнутри.
> выданный на мою организацию OID прописываеться при создании Issuing CA в CAPolicy.inf ? тут могут быть варианты. Если вы в CAPolicy.inf пропишите свой OID, вы ограничите свои сертификаты только вашим деревом. Чтобы иметь возможность расширять политики за счёт других стандартных политик выдачи (OID'ов), в CAPolicy.inf прописываете общий OID = 2.5.29.32.0, а в шаблонах сертификатов прописываете OID, выданный на вашу организацию.
Спасибо !
Доброго всем времени суток. Косметический момент (просмотрел ветку, вроде не писали ещё об этом) - на шаге 2 в комментариях к параметрам CRL в файле capolicy.inf упоминаются параметры от файла для rootca. Может быть это для вас важно...
> в файле capolicy.inf упоминаются параметры от файла для rootca потому что они могут использоваться и для подчинённых CA тоже.
Извиняюсь, возможно не достаточно точно выразился, хотя это на работу скрипта не влияет, ибо цифры правильные, но для пущего порядка может быть важно. Я имел ввиду, что описание параметров в комментариях от rootca - т.е. написано "...публиковать новый CRL каждые 90 дней, а срок действия этого CRL будет 104 дня"
Вадимс, приветствую. Перерыл много страниц Инета, но не нашёл как сделать так, чтобы ссылка (кнопка) "Issuer Statement" появлялась не только в сертификате самого издающего сервера (делалось всё по вашей доке с разделом [PolicyStatementExtension] в CAPolicy.inf), но и в итоговых сертификатах, которые он выпускает. Не подскажите (или ссылку может быть)?
Это решается путём добавления Issuance Policy в шаблоне сертификатов (вкладка Extensions).
Добрый день. Прошу прощения, если вопрос глупый, но нигде не нашел ответ. Допустим, уже имеется развернутая инфраструктура из корневого и выдающего ЦС. При развертывании выдающего ЦС конфигурационный файл CAPolicy.inf не создавался (вы написали, что в данном случае будет создан конфигурационный файл с настройками по умолчанию). Собственно вопрос: Как называется и где находится данный файл, и возможно ли его редактирование для добавления роли Policy CA на выдающий ЦС (с последующим перевыпуском необходимых сертификатов), чтобы у каждого пользователя появилась возможность по нажатию на кнопку Issuer Statement просмотра регламента УЦ?
Нет, сам он создаваться не будет, просто CA будет подразумевать настройки по умолчанию. Файл называется CAPolicy.inf и он должен располагаться в корне системной папки, по умолчанию это C:\Windows да, вы можете создать такой файл, прописать там все необходимые параметры (например заполнить секцию для CPS) и обновить сертификат самого CA.
Comments: