Планирование инфраструктуры PKI
Эта статья является частью серии статей про упрощенную установку Certification Authority (CA) в тестовом окружении.
После выбора схемы иерархии, необходимо выбрать:
- срок действия сертификата CA;
- сроки действия издаваемых сертификатов;
- сроки действия Base CRL и Delta CRL;
- срок действия перекрытия (overlap) Base CRL и Delta CRL;
- использование OCSP Online Responder;
- CRL Distribution Points (CDP) и Authority Information Access (AIA).
Необходимо заранее спланировать изменения, которые будут вносится в настройки CA, как минимум, это параметры CDP и AIA расширений. Их необходимо внести сразу после установки, и до выдачи первых сертификатов. По умолчанию, некоторые шаблоны помечены для автоматического издания. Доменный контроллер запросит себе два сертификата сразу же, как только обнаружит появление CA. Это произойдет при автоматическом обновлении групповых политик. По этой причине, после полной настройки CA нужно будет убедится, что ни один сертификат еще не был выдан.
Выбор срока действия сертификата CA
Срок действия сертификата CA рекомендуется выбирать в пределах 5-20 лет. Чем больше, тем реже придется заниматься его распространением, но и тем больше будет проблем при компрометации этого сертификата. Для одноуровневой иерархии срок действия сертификата CA по умолчанию 5 лет. Срок действия сертификата CA выбирается при его установке или вышестоящим CA.
Выбор сроков действия издаваемых сертификатов
Значение по-умолчанию 2 года. Шаблоны переопределяют это значение.
Значение по умолчанию:ValidityPeriod REG_SZ = Years
ValidityPeriodUnits REG_DWORD = 2
Получить текущий срок действия издаваемых сертификатов:certutil -getreg CA\ValidityPeriod
certutil -getreg CA\ValidityPeriodUnits
Пример изменения срока действия издаваемых сертификатов:certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\ValidityPeriodUnits 2
Срок действия Base CRL и Delta CRL
Существует два типа CRL: Base CRL и Delta CRL. В случае если Delta CRL не используется, сертификаты считаются недействительными если Base CRL недоступен или просрочен. В случае если Delta CRL используется, Base CRL и Delta CRL должны быть доступны и действительны для успешной проверки сертификатов. Подробнее в technet: How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated.
Со временем CRL может очень сильно вырасти в размерах. Чтобы уменьшить нагрузку по получению CRL, используется Delta CRL.
Значение по умолчанию:CRLPeriod REG_SZ = Weeks
CRLPeriodUnits REG_DWORD = 1
CRLDeltaPeriod REG_SZ = Days
CRLDeltaPeriodUnits REG_DWORD = 1
Получить текущий срок действия Base CRL:certutil -getreg CA\CRLPeriod
certutil -getreg CA\CRLPeriodUnits
Получить текущий срок действия Delta CRL:certutil -getreg CA\CRLDeltaPeriod
certutil -getreg CA\CRLDeltaPeriodUnits
Пример изменения срока действия Base CRL:certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLPeriodUnits 1
Пример изменения срока действия Delta CRL:certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 1
Срок действия перекрытия (overlap) Base CRL и Delta CRL
Для успешной проверки действительности сертификата, CRL полученный клиентом должен быть действительным. Однако распространение CRL может занять время, например в случае репликации LDAP.
Значение по умолчанию:CRLOverlapPeriod REG_SZ = Hours
CRLOverlapUnits REG_DWORD = 0
CRLDeltaOverlapPeriod REG_SZ = Minutes
CRLDeltaOverlapUnits REG_DWORD = 0
Получить текущий период перекрытия Base CRL:certutil -getreg CA\CRLOverlapPeriod
certutil -getreg CA\CRLOverlapUnits
Получить текущий период перекрытия Delta CRL:certutil -getreg CA\CRLDeltaOverlapPeriod
certutil -getreg CA\CRLDeltaOverlapUnits
Пример изменения периода перекрытия Base CRL:certutil -setreg CA\CRLOverlapPeriod "Hours"
certutil -setreg CA\CRLOverlapUnits 24
Пример изменения периода перекрытия Delta CRL:certutil -setreg CA\CRLDeltaOverlapPeriod "Hours"
certutil -setreg CA\CRLDeltaOverlapUnits 12
Использование OCSP Online Responder
OCSP снижает накладные расходы при проверках сертификатов. Однако ссылка на OCSP Online Responder должна быть включена в проверяемый сертификат. Также возможно указать OCSP Responder через групповые политики.
Суть работы OCSP простая. Клиент для проверки статуса сертификата отправляет запрос на OCSP Responder с указанием серийного номера проверяемого сертификата. OCSP Responder на своей стороне проверяет статус сертификата и возвращает этот статус клиенту.
Однако использовать протокол OCSP умеют только клиенты под управлением Windows Vista и выше. Предыдущие ОС могут его поддерживать только за счёт сторонних компонентов.
CRL Distribution Points (CDP) и Authority Information Access (AIA)
- В расширении «CRL Distribution Points (CDP)» хранятся ссылки на CRL издавшего конкретный сертификат CA;
- В расширении «Authority Information Access (AIA)» хранятся ссылки на сертификат CA, издавшего конкретный сертификат. А для сертификатов, выданных CA под управлением Windows Server 2008 и выше — могут содержаться ссылки на OCSP Responder.
В некоторых PKI инфраструктурах имеет смысл отказаться от LDAP ссылок в сертификатах в пользу HTTP. Это особенно важно для клиентов не являющихся членом домена, у них просто не будет доступа к LDAP, а время на попытку проверить сертификат в LDAP будет потрачено, поскольку по умолчанию ссылка на него стоит первой. Однако в других случаях, отказ от LDAP ссылок будет скорее вреден, чем полезен. Ведь обеспечить доступность LDAP значительно проще, чем HTTP. Серверов LDAP в AD обычно двое (PDC и BDC), это стандартная и рекомендуемая конфигурация. А вот HTTP сервер обычно один, да еще и территориально удален. Как итог, в случае банального повреждения сети, может перестать работать внутренняя авторизация, и это при живых PDC и BDC. Смешно, не правда-ли. Как средний вариант, можно рассмотреть возможность изменения порядка следования ссылок в сертификатах, чтобы http ссылка была первой, а LDAP второй. Но как универсальное решение проблемы, такую конфигурацию рассматривать не стоит. Проверка по LDAP ссылкам скорее всего будет выполняться быстрее. «Скорее всего» это потому, что у меня нет документальных подтверждений этого утверждения, однако я встречал подобное мнение. Да и логика подсказывает, что LDAP сервера будут располагаться ближе, чем HTTP сервер компании.
Обратите внимание, что хоть использование HTTPS ссылок допустимо, но несет в себе возможные проблемы в виде зацикливания проверки. При запросе к HTTPS серверу требуется проверить его сертификат. Чтобы проверить сертификат HTTPS сервера, нужно сделать запрос к этому-же HTTPS серверу. В итоге проверка сертификата HTTPS сервера станет невозможной, она будет прервана по таймауту и сертификат останется непроверенным. Впрочем, ничто не мешает использовать HTTPS сервер, сертификат которого выдан другим Issuing CA. При острой необходимости использования HTTPS для проверки сертификатов, внимательно продумайте иерархию PKI, чтобы избежать подобной проблемы.
Значение по умолчанию для CDP:CRLPublicationURLs REG_MULTI_SZ =
0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
2: 0:http://%1/CertEnroll/%3%8%9.crl
3: 0:file://%1/CertEnroll/%3%8%9.crl
Значение по умолчанию для AIA:CACertPublicationURLs REG_MULTI_SZ =
0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
1: 3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
2: 0:http://%1/CertEnroll/%1_%3%4.crt
3: 0:file://%1/CertEnroll/%1_%3%4.crt
Получить текущее значение CDP:certutil -getreg CA\CRLPublicationURLs
Получить текущее значение AIA:certutil -getreg CA\CACertPublicationURLs
Пример внесения изменений в CDP:certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:http://%1/CertEnroll/%3%8%9.crl\n0:file://%1/CertEnroll/%3%8%9.crl"
Пример внесения изменений в AIA:certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://%1/CertEnroll/%1_%3%4.crt\n0:file://%1/CertEnroll/%1_%3%4.crt\n32:http://%1/ocsp"
Обратите внимание, что если certutil
будет вызываться из командного файла, то символ процента необходимо экранировать еще одним символом %. Например, вместо %1 в bat/cmd файле необходимо будет написать %%1.
Пример внесения изменений в CDP из командного файла:certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://%%1/CertEnroll/%%3%%8%%9.crl\n0:file://%%1/CertEnroll/%%3%%8%%9.crl"
Пример внесения изменений в AIA из командного файла:certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt\n0:file://%%1/CertEnroll/%%1_%%3%%4.crt\n32:http://%%1/ocsp"
Для формирования строчек для настройки CDP / AIA понадобится справочная информация об используемых кодах.
Ссылки в расширениях CDP и AIA можно изменить и добавить двумя способами. При помощи certutil.exe и при помощи оснастки certsrv.msc. Однако при помощи оснастки certsrv.msc нельзя поменять порядок следования ссылок в сертификатах. И если планируется изменить порядок по умолчанию, то certutil.exe остается единственным выбором. Единственным, потому, что через оснастку доступны не все свойства ссылок. Взгляните сами на дефолтные ссылки AIA из свежеустановленного CA. Для LDAP ссылки установлено свойство CSURL_SERVERPUBLISH, однако в оснастке просто нет возможности установить это свойство. Интересно, не правда-ли.
Планирование CDP
№ | Код | Ссылка и используемые параметры |
0 | 65 | C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
|
1 | 79 | ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
|
2 | 6 | http://%1/CertEnroll/%3%8%9.crl
|
3 | 0 | file://%1/CertEnroll/%3%8%9.crl
|
Примечания и отличия от конфигурации по-умолчанию:
- для ссылки 2 добавлены две опции, т.е. включается добавление в издаваемые сертификаты HTTP ссылки;
- ссылка 3 не меняется, поскольку IIS сервер находится на сервере CA, и публикация для HTTP сервера выполняется по ссылке 0.
Итоговая команда для изменений при помощи certutil.exe:
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:http://%1/CertEnroll/%3%8%9.crl\n0:file://%1/CertEnroll/%3%8%9.crl"
Она же, но в случае выполнения из командного файла:
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://%%1/CertEnroll/%%3%%8%%9.crl\n0:file://%%1/CertEnroll/%3%8%9.crl"
Планирование AIA
№ | Код | Ссылка и используемые параметры |
0 | 1 | C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
|
1 | 3 | ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
|
2 | 2 | http://%1/CertEnroll/%1_%3%4.crt
|
3 | 0 | file://%1/CertEnroll/%1_%3%4.crt
|
4 | 32 | http://%1/ocsp
|
Примечания и отличия от конфигурации по-умолчанию:
- параметры для ссылки 0 невозможно задать из оснастки certsrv.msc;
- параметры для ссылки 1 невозможно задать из оснастки certsrv.msc;
- для ссылки 2 включена публикация в издаваемых сертификатах;
- ссылка 3 не меняется, поскольку HTTP сервер находится на сервере CA, и публикация для HTTP сервера выполняется по ссылке 0;
- добавлена ссылка 4 с публикацией ссылки на OCSP Responder; если не добавить эту ссылку то нет никакого смысла ставить сервис Online Responder.
Итоговая команда для изменений при помощи certutil.exe:
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://%1/CertEnroll/%1_%3%4.crt\n0:file://%1/CertEnroll/%1_%3%4.crt\n32:http://%1/ocsp"
Она же, но в случае выполнения из командного файла:
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt\n0:file://%%1/CertEnroll/%%1_%%3%%4.crt\n32:http://%%1/ocsp"
Чеклист
Рекомендую все планируемые изменения в конфигурацию оформить в виде таблицы. Это поможет быстро и правильно развернуть роль AD CS. Вот пример такой таблицы:
Название | Название параметра в certutil | Значение по-умолчанию | Выбранное значение |
Имя CA | YourName Root Certification Authority | ||
Тип CA | |||
Срок действия сертификата CA | 5 Years | 10 Years | |
Срок действия издаваемых сертификатов | |||
Время действия издаваемых сертификатов | CA\ValidityPeriodUnits | 2 | |
Единица измерения срока действия издаваемых сертификатов | CA\ValidityPeriod | Years | |
Срок действия Base CRL | |||
Период достоверности Base CRL | CA\CRLPeriodUnits | 1 | |
Единица измерения периода достоверности Base CRL | CA\CRLPeriod | Weeks | |
Срок действия Delta CRL | |||
Период достоверности Delta CRL | CA\CRLDeltaPeriodUnits | 1 | |
Единица измерения периода достоверности Delta CRL | CA\CRLDeltaPeriod | Days | |
Перекрытие периода действия Base CRL | |||
Время до истечения срока действия текущего основного CRL, за которое будет публиковаться новый основной CRL. | CA\CRLOverlapUnits | 0 | 24 |
Единица измерения этого времени для основного CRL (Hours|Minutes) |
CA\CRLOverlapPeriod | Hours | Hours |
Перекрытие периода действия Delta CRL | |||
Время до истечения срока действия текущего инкрементального (если используется) CRL, за которое будет публиковаться новый инкрементальный CRL (максимум 12 часов) |
CA\CRLDeltaOverlapUnits | 0 | 12 |
Единица измерения этого времени для инкрементального CRL (Hours|Minutes) |
CA\CRLDeltaPeriodPeriod | Minutes | Hours |
Использовать OCSP | Yes | ||
CDP extension | CA\CRLPublicationURLs | File, LDAP | File, LDAP, HTTP |
AIA extension | CA\CACertPublicationURLs | File, LDAP | File, LDAP, HTTP, OCSP |
Конфигурационный скрипт для Certification Authority
До установки роли AD CS необходимо создать конфигурационный скрипт, который выполнит послеустановочную настройку CA на основании выбранных параметров. Ниже следует пример такого скрипта:
CAScript.cmd
:: CDP
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://%%1/CertEnroll/%%3%%8%%9.crl\n0:file://%%1/CertEnroll/%%3%%8%%9.crl"
:: AIA
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt\n0:file://%%1/CertEnroll/%%1_%%3%%4.crt\n32:http://%%1/ocsp"
:: В случае использования роли OCSP, при обновлении сертификата CA могут быть
:: проблемы с проверкой подлинности сертификатов. Чтобы устранить эту проблему
:: используется:
certutil –setreg CA\UseDefinedCACertInRequest 1
:: Включаем наследование Issuer Statement в издаваемых сертификатах
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"
:: Задаём срок действия издаваемых сертификатов
::certutil -setreg CA\ValidityPeriodUnits 2
::certutil -setreg CA\ValidityPeriod "Years"
:: Задаём параметры публикации CRL
::certutil -setreg CA\CRLPeriodUnits 1
::certutil -setreg CA\CRLPeriod "Weeks"
::certutil -setreg CA\CRLDeltaPeriodUnits 1
::certutil -setreg CA\CRLDeltaPeriod "Days"
:: Меняем параметры CRL Overlap
certutil -setreg CA\CRLOverlapUnits 24
certutil -setreg CA\CRLOverlapPeriod "Hours"
certutil –setreg CA\CRLDeltaOverlapUnits 12
certutil –setreg CA\CRLDeltaOverlapPeriod "Hours"
:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127
:: Перезапускаем сервис CA
net stop certsvc && net start certsvc
:: Публикуем новый CRL в новую локацию.
certutil -CRL
Добрый день!
А каким образом можно оперативно узнавать отозван ли сертификат или нет. Ведь списки отзыва CRL и Delta CRL публикуются периодично и в период между их публикацией можно отозвать сертификат, а его еще не будет в списке отзыва и пользователь с этим сертификатом будет легитимным, хотя на самом деле сертификат уже отозван. Как решить такую задачу?