Contents of this directory is archived and no longer updated.

Posts on this page:

Тут от одного пользователя поступила небольшая кучка вопросов. Вопросов достаточно и я решил их опубликовать и ответить в бложеке (оригинальная орфография сохранена). Вопросы в италике, ответы не в италике.

1. У вас практически во всех примерах не более трёх путей публикации (в некоторых обсуждениях - четыре) - два файловых локальных пути и
внешний web в самой статье. Когда вы пишите про LDAP, то пути также три - один файловый, внешний web  и LDAP. Это опять же связано с
таймаутом 20 секунд на обработку расширений? Т.е. больше - плохо?

Точек распространения файлов может быть сколько угодно. А вот точек публикаций не должно превышать 2-х, т.к. чисто технически 3-я (и последующие) работать уже не будут ни при каком раскладе. Об этом ниже.


Read more →

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 NTAuthCA

net 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. Для этого выполните следующее:

  1. Откройте оснастку Online Responder из папки Administrative Tools.
  2. Выделите Revocation configuration и в меню Action выберите Add Revocation Configuration.
  3. Откроется мастер создания конфигурации отзыва. Ознакомьтесь с предстоящими шагами и нажмите Next.
  4. Укажите имя новой конфигурации. Например: RootCA 1. Единичка будет означать номер ключа CA для которого настроена конфигурация. Дело в том, что при каждом обновлении сертификата CA с новой ключевой парой вам необходимо будет создавать новую конфигурацию в OCSP. Нажмите Next.
  5. На странице Select CA Certificate Location выберите Import certificate from a file и нажмите Next.
  6. На следующей странице укажите путь к файлу сертификата корневого CA и нажмите Next.
  7. На странице Select Signing Certificate укажите Manually select signing certificate и нажмите Next.
  8. На странице Revocation Provider вы можете получить сообщение об ошибке, которая сообщает о том, что мастер не смог получить сведения о конфигурации CA. Это связано с тем, что наш Offline Root CA не подключен к сети и вообще находится в сейфе. Поэтому нажмите кнопку Provider и укажите ссылку на CRL корневого центра сертификации. По условиям нашего сценария, ссылка будет иметь следующий вид:
    http://www.adatum.com/pki/Adatum_RCA.crl

    Поскольку корневой CA не использует Delta CRL, оставьте это поле пустым. Так же вы можете настроить периодичность, с которой OCSP будет освежать свой внутренний кеш. Например, можно указать каждые 10 минут. Нажмите Ok и вернитесь в мастер создания конфигурации OCSP.
  9. Нажмите Finish для завершения работы мастера.

Вы вернётесь обратно в оснастку OCSP Responder и увидите, что наша созданная конфигурация выдаёт ошибку, поскольку нет сертификата подписи, который будет использоваться для подписи ответов OCSP. Для устранения этого недостатка, разверните секцию Array Configuration и выделите нужный респондер (предполагается, что это тот же самый сервер, на котором вы настраиваете OCSP). В центральной панели выберите конфигурацию RootCA 1 и в панели Actions нажмите на Assign Signing Certificate. Откроется список пригодных сертификатов. Скорее всего он там будет один. Поэтому выберите его и нажмите Ok.

Теперь выделите Array Configuration и в меню Action нажмите Refresh Revocation Data. И вот что вы должны увидеть в конечном итоге:

OCSP Responder configurations

Results

Для окончательной проверки мы можем запустить оснастку PKIView.msc. Если мы настроили всё правильно, то должны увидеть примерно такой вид:

Reviewing CA installation results

Reviewing CA installation results

И подведём итоги того, что мы сделали:

  • Мы спланировали типовую 2-х уровневую иерархию и конфигурацию PKI, которая включает в себя Offline Root CA и Online Issuing CA;
  • Установили и сконфигурировали соответствующим образом наш корневой Root CA, который может быть нормально выключен и который будет издавать сертификаты только для других центров сертификации;
  • Установили и сконфигурировали подчинённый Issuing CA, который будет издавать сертификаты уже конечным потребителям.
  • Настроили OCSP Responder для работы с Offline Root CA.

Вроде бы выглядит немного, но исходя из материала мы проделали достаточно большой объём работы, в результате мы получили достаточно гибку и, главное, работающую PKI.

17

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

КДПВ Предлагаю немного отвлечься от autoenrollment и поговорить о часто задаваемым вопросам, которые относятся к проблемам certificate chaining engine. Данный FAQ основывается на вопросах, которые часто задаются на форумах TechNet.





Q: За что отвечают расширения CRL Distribution Points (CDP) и Authority Information Access (AIA) в цифровых сертификатах?

A: Расширение Authority Information Access всегда содержит ссылки на сертификат Certification Authority (CA), который издал рассматриваемый сертификат. Например, у вас есть сервер CA, который издаёт пользователям сертификаты. Каждый такой сертификат будет содержать ссылку на скачивание сертификата этого самого CA. Это необходимо для построения цепочки сертификатов. Как известно, любая иерархия PKI включает себя как минимум один корневой CA (Root CA) и может содержать несколько уровней промежуточных CA. Используя расширение AIA конечного сертификата, клиент скачивает сертификат издающего CA, который в расширении AIA так же содержит ссылки на скачивание сертификата вышестоящего CA. Этот процесс происходит до тех пор, пока цепочка не закончится самоподписанным сертификатом и который уже не содержит расширения AIA. Поскольку корневой сертификат самоподписанный, он является конечной точкой цепочки. По корневому сертификату определяется доверие цепочке. Чтобы доверять такой цепочке, корневой сертификат, на котором эта цепочка заканчивается, должен быть установлен в контейнере Trusted Root CAs в оснастке Certificates консоли MMC.
Расширение CRL Distribution Point содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. Сертификаты могут быть отозваны, когда есть подозрения или уже констатирован факт получения несанкционированного доступа к закрытому ключу третьим лицом. Закрытый ключ должен быть доступен только тому пользователю или компьютеру, которому выдан данный сертификат. Если третье лицо получило доступ к закрытому ключу, это лицо может воспользоваться им для получения конфиденциальной информации или выдавать себя за легитимного пользователя. В таких случаях администратор CA может отозвать такой сертификат. В таком случае если сертификат содержится в файле CRL, предъявителю данного сертификата никакого доверия не будет. Следует понимать, что CDP/AIA рассматриваемого сертификата содержат ссылки на файлы вышестоящего CA. Даже если владельцем рассматриваемого сертификата является сервер CA (Intermediate CA), ссылки будут указывать на файлы вышестоящего CA.
Более подробно вопрос рассмотрен по ссылке: Certificate Chaining Engine — как это работает.

Q: Нужны ли расширения CDP и AIA в сертификатах корневых CA?

A: Нет. Как уже было сказано, CDP и AIA содержат ссылки на файлы вышестоящего CA, а корневой сертификат является высшей точкой в иерархии и выше корневого CA ничего быть не может. Поэтому данные расширения бесполезны для сертификатов корневых CA и обычно просто отсутствуют.
Более подробно вопрос рассмотрен здесь: Certificate chaining engine (CCE) и отзыв корневых сертификатов

Q: На каком сервере CA я могу отозвать определённый сертификат?

A: каждый сервер CA поддерживает свой список CRL в который может включать только те сертификаты, которые были выданы именно этим CA. Это означает, что сертификат отозвать может только CA, который указан в поле Issuer рассматриваемого сертификата.

Q: Стоит ли использовать Certificate Hold в качестве причины отзыва сертификата? Если да, то в каких случаях?

A: Причина отзыва как Certificate Hold обладает одной особенностью — его можно извлечь обратно из CRL файла, после чего он перестанет считаться отозванным. Данная причина задумана для случаев когда сотрудник уходит в отпуск и такой отзыв позволит избежать использование отозванного сертификата на этот период. Однако, данную причину не следует никогда использовать. Это связано с тем, что после извлечения сертификата из CRL вы не можете узнать был ли он отозван в какой-то период времени. Например, вы отозвали сертификат с причиной Certificate Hold и через некоторое время передумали и извлекли сертификат из CRL. В последствии вы получаете документ, подписанный этим сертификатом именно в период фактического нахождения сертификата в CRL. Фактически получается, что документ был подписан в тот момент, когда сертификат был отозван. Поскольку он был потом извлечён из CRL, вы больше не можете доказать, что сертификат был отозван на момент подписания документа. По этой причине вы не должны использовать данную причину отзыва.

Q: При установке сертификата на сервер иногда получаю ошибку: The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613). Что это может означать и как эту ошибку исправить?

A: Данная ошибка указывает на то, что системе не удалось проверить сертификат на отзыв. Иными словами, система извлекла ссылку из CDP расширения сертификата и по этой ссылке не удалось скачать CRL файл. В данном случае вы должны обратиться к администратору сервера CA, чтобы тот обеспечил доступность файла по ссылкам в CDP расширении. Если же вы сами исполняете эти обязанности, то вы должны самостоятельно решить этот вопрос — настроить точки публикации CRL файлов. В качестве временного решения (например, вы опубликовали CRL только в Active Directory и у вас несколько доменов в лесу, причиной этого может быть репликация AD. В таком случае вы можете скачать CRL файл локально на компьютер (любым удобным способом) и выполнить команду: certutil –addstore –f Root <path\file.crl>
где <path\file.crl> — путь к файлу CRL.

Q: При открытии файла сертификата я вижу следующее сообщение: Windows does not have enough information to verify this certificate. Что это означает и как с этим бороться?

A: Данное сообщение говорит о том, что системе не удалось найти сертификат вышестоящего CA. Как уже было отмечено, этот сертификат можно скачать по ссылке (ссылкам) в расширении AIA, но по всей видимости они нерабочие. Вы можете попробовать вручную скачать файл по этим ссылкам и вероятней всего вам это не удастся. Для решения этой проблемы вы должны опубликовать физический файл в соответствующие места: папка веб-сервера (для протокола HTTP) или контейнер AIA в Active Directory (для протокола LDAP). Если файл сертификата CA публикуется только в AD и у вас лес с несколькими доменами, данная ошибка может быть кратковременно вызвана задержками репликации. В таком случае для временного решения вы можете скачать файл на локальную машину (любым удобным для вас способом) и выполнить одну из двух команд:
certutil –addstore –f SubCA <path\file.crt> — если вышестоящий CA не является корневым
certutil –addstore –f Root <path\file.crt> — если вышестоящий CA является корневым.
где <path\file.crt> — путь к файлу CER/CRT.

Q: Я отозвал сертификат, опубликовал новый CRL, однако при запуске файла сертификата я не вижу ошибок, что сертификат отозван. Почему?

A: Когда вы запускаете файл сертификата (просматриваете его содержимое), проверка на отзыв не происходит. Система только строит цепочку, но ни один сертификат на отзыв не проверяется. Это by design. Для проверки статуса сертификата вы можете воспользоваться следующими командами:
certutil –url <path\file.cer> — этой командой вызывается удобный графический интерфейс, в котором вы можете выяснить статус отзыва сертификата.
certutil –verify –urlfetch <path\file.cer> — данная команда выведет очень подробный текстовый лог проверки. Рекомендуется для использования профессионалами, которые в состоянии проанализировать этот лог.
где <path\file.cer> — путь к файлу проверяемого сертификата.

Q: Я отозвал сертификат, опубликовал новые CRL, однако certutil показывает, что сертификат не отозван. Как так?

A: Это вызвано тем, что CRL'ы, как и ответы от OCSP Responder кешируются в оперативной памяти и жёстком диске. Для обновления кеша в памяти, следует перезапустить приложение, которое проверяет статус сертификата. А на самом диске CRL кешируется на срок действия конкретного CRL. Это значит, что клиент будет использовать данный кешированный CRL до срока указанного в поле Next update конкретного CRL файла. Кеширование используется для экономии ресурсов и пропускной способности сети. Но вы можете очистить кеш CRL (при этом удалятся все кешированные CRL), вы можете воспользоваться следующей командой:
certutil -setreg chain\ChainCacheResyncFiletime @now
после этого обязательно следует выполнить следующую команду:
certutil –delreg chain\ChainCacheResyncFiletime
Данные команды поддерживаются системами начиная с Windows XP SP3. Предыдущие системы не поддерживают очистку кеша CRL.

Q: Какие протоколы разрешены для расширений CDP/AIA?

A: Для Windows систем доступны только следующие протоколы:
HTTP:// — только для публикации в расширение сертификата.
LDAP:// — для публикации физических файлов и для публикации ссылки в расширение сертификата.
FILE:// — только для публикации физических файлов в сетевой папке (например, на веб-сервере). Хотя Windows Server 2003 и предыдущие системы позволяли такие ссылки в расширениях CDP/AIA, начиная с Windows Vista/Windows Server 2008 они больше не допускаются и не используются.
C:\path — только для публикации физических файлов в файловой системе локального компьютера.
Более подробно можно прочитать по ссылке: CRL Distribution Points и Authority Information Access

Q: есть ли какие-то best practices по планированию расширений CDP/AIA?

A: да, существют определённые best practices по настройке расширений CDP/AIA на сервере CA. И вот как они выглядят в общем виде:
1) не следует использовать ссылки вида LDAP:// если ваши сертификаты могут использоваться вне пределах вашего леса AD. Это вызвано тем, что скачивать файлы по таким ссылкам могут только клиенты текущего леса, остальные клиенты будут получать ошибки по этим ссылкам. Целесообразно использовать более универсальные протоколы как HTTP. Данный протокол поддерживается множеством систем, в том числе и мобильными системами (смартфоны) и пользователями других операционных систем. При использовании HTTP рассмотрите возможность высокой доступности этих веб-серверов, как NLB-кластер или использования двух различных веб-серверов. В таком случае вы должны будете указать ссылки на скачивание файла для каждого веб-сервера.
2) используйте веб-сервера, которые доступны как изнутри сети, так и из интернета (если сертификаты могут использоваться пользователями интернета, например SSL-сертификаты) по одному и тому же URL.
3) при планировании ссылок, которые будут публиковаться в расширениях CDP/AIA сертификатов следует учитывать их очерёдность. Если вы решили использовать 2 независимых веб-сервера, первым указывайте тот, который будет являться основным. Это обусловлено тем, что клиент скачивает файлы по ссылкам в порядке их следования. Первая ссылка будет использоваться в первую очередь. Для ссылок публикации физического файла очерёдность не имеет значения.
4) для HTTP ссылок никогда не используйте SSL (т.е. HTTPS ссылки), поскольку это вызовет бесконечную проверку сертификатов, в результате чего вы никогда не скачаете нужный файл.
Более подробно можно прочитать по ссылкам: CRL Distribution Points и Authority Information Access, OCSP или CRL?

Q: Какие версии ОС Windows поддерживают нативного клиента OCSP?

A: Только ОС начиная с Windows Vista/Windows Server 2008 включают в себя клиента OCSP. Предыдущие системы никогда не поддерживали и не будут поддерживать клиента OCSP. Для них придётся приобретать отдельный программный продукт сторонних компаний.

Q: Я хочу использовать OCSP Responder как для внутренней, так и для внешней сети (интернета). На какое имя должен выдаваться сертификат OCSPResponseSigning?

A: на самом деле клиенту всё равно на какое имя выдаётся данный сертификат. Главное — сертификат должен отвечать следующим условиям:
1) должен быть выдан тем же CA для которого OCSP Responder осуществлял проверку статуса сертификата.
2) в Application Policies (Extended Key Usage) должен быть указан: OCSP Signing
3) в сертификате должно присутствовать расширение: OCSP No Revocation Checking
4) срок действия сертификата должен быть действующий.

Q: Мы в компании перешли на Windows Vista/Windows 7 и развернули OCSP Responder. Однако в сети уже выпущено огромное количество сертификатов, которые не содержат ссылок на OCSP Responder. Надо ли перевыпускать все сертификаты для включения в них ссылки на OCSP?

A: нет, вам не нужно перевыпускать все сертификаты, которые уже используются. Вы можете для доменных клиентов настроить групповую политику так, чтобы они получили адрес вашего OCSP Responder и которым они будут пользоваться при проверке сертификатов. В качестве руководства по настройке этой политики можете воспользоваться вот этой ссылкой: Appendix A: Managing OCSP Settings with Group Policy

Что бы почитать?

Этим постом я начинаю серию небольших заметок по не всегда очевидным фактам в PKI. И сегодня начну с первого факта — OCSP или CRL? OCSP и CRL — это 2 модели, которые могут использоваться для проверки сертификата на предмет его отзыва.

Сертификаты в случае когда в них больше не нуждаются или когда закрытый ключ от сертификата может быть доступен злоумышленникам подлежат отзыву. Этим самым полностью теряется доверие данному сертификату или человеку, который его предъявил, поскольку сертификат может предъявить злоумышленник, который его украл. Это достаточно важный момент в PKI, который позволяет достаточно однозначно сказать — можем ли мы доверять предъявителю конкретного сертификата или нет.

Модель CRL используется с самого начала существования PKI и выглядит следующим образом. Сервер CA отзывает некоторый сертификат и помещает о нём запись в специальный файл CRL. При этом туда помещается серийный номер сертификата, дата фактического отзыва (не обязательно совпадает со временем когда администратор отозвал сертификат) и причина отзыва. Клиенты при проверки сертификатов скачивают эти CRL и проверяют есть ли серийный номер этого сертификата в CRL. Логично, что чем больше сертификатов отозвано, тем больше файл, тем более нагружается сеть при частом скачивании относительно большого файла CRL.

В OCSP используется немного иной принцип. Клиент OCSP отправляет на сервер OCSP Responder специальный запрос, в котором содержится серийный номер проверяемого сертификата. OCSP Responder «пробивает номер по своей базе» и отвечает клиенту откликом. Этот отклик содержит однозначный ответ на вопрос: отозван или не отозван.

Казалось бы, если у вас и серверы и клиенты работают под управлением Windows Vista/2008 и выше, то ответ однозначный: OCSP — наше всё! Ну и вообще даже при наличии небольшого количества этих систем (а преимущественно используются устаревшие клиенты Windows XP/2003), то OCSP нам никак не помешает! Но на самом деле это не всегда так и в ряде ситуаций использование OCSP будет даже нежелательным. Давайте посмотрим почему. Сначала сделаем сравнительные характеристики обеих моделей проверки отзыва

  • CRL

Исходный размер пустого CRL составляет порядка 600 байт (но это значение может отличаться в зависимости от длины полей и длины ключа подписи). На каждую запись отозванного сертификата в CRL отводится 80 байт. Это, как я уже говорил, серийный номер отозванного сертификата, дата фактического отзыва и числовое обозначение причины отзыва. Т.е. если у вас отозвано 10 сертификатов, то размер CRL будет 600 + 80 * 10 = 1400 байт. Если отозвано 100 сертификатов, то размер CRL будет порядка 9кб и т.д.

  • OCSP

Каждая проверка статуса сертификата потребляет определённый размер трафика — 2кб. При этом неважно какого размера сам CRL. Даже если отозвано 100 000 сертификатов, то CRL будет размером примерно 8мб. И каждый устаревший клиент будет скачивать этот файл на 8 мегабайт. А с OCSP любой запрос и ответ на него займёт всего 2кб. Удобно? Безусловно.

Однако, в ряде случаев я бы не рекомендовал использовать OCSP для сертификатов, которые аутентифицируют клиентов. К ним относятся следующие типы сертификатов:

  • сертификаты смарт-карт;
  • сертификаты аутентификации в IIS;
  • клиентские сертификаты компьютеров для VPN/L2TP и IPsec;
  • сертификаты аутентификации пользователей в VPN (EAP-TLS).

Почему? Дело в том, что аутентифицирующий сервер кеширует все данные об отзыве. Сначала в памяти, потом на диске (когда происходит свопинг). И давайте посмотрим на типичный сценарий:

У вас на предприятии используется корпоративный веб-сайт с аутентификацией пользователей по сертификату. У вас 1000 пользователей и они все утром подключаются к веб-сайту. Веб-сервер при проверке подлинности каждого пользователя будет посылать OCSP запрос на OCSP Responder запросы с серийным номером каждого сертификата. Мы знаем, что размер каждого ответа составляет 2кб, следовательно сервер отправит 1000 HTTP запросов и закеширует у себя в памяти 2 мегабайта памяти.

А теперь представьте, что у вас не используется OCSP, а только CRL и на сервере CA отозвано 100 сертификатов. Как мы знаем сам контейнер CRL занимает 600 байт и каждая запись по 80 байт. В итоге файл CRL будет занимать 9 килобайт! И в этом случае сервер сделает только одну «ходку» за CRL файлом и уже всех клиентов будет проверять именно по скачанному CRL. Как видите, профит от использования CRL здесь очевиден. Серверу надо меньше тратить сетевого трафика и меньше данных кешируется в памяти. При этом OCSP целесообразно включать для серверных сертификатов, потому что клиентов обычно много и им выгодней использовать небольшии порции трафика OCSP.

Подводя итоги, мы можем кратко констатировать следующие вещи:

  • для серверных сертификатов рационально использовать OCSP;
  • для клиентских сертификатов, которые используются для аутентификации часто рациональней будет использовать классические CRL, вместо OCSP.

Поэтому при рассмотрении вопроса внедрения OCSP вы должны учитывать эти моменты, чтобы ваша PKI была более эффективной.

Ссылки по теме:

OCSP (часть 1)
OCSP (часть 2)
http://en.wikipedia.org/wiki/Certificate_revocation_list

Это будет краткая заметка по решению одной проблемы (пока причина проблемы не установлена) при установке OCSP Responder на контроллере домена под управлением Windows Server 2008 R2 RTM. При такой установке у вас в Application Log может появиться сообщение:

Log Name:      Application
Source:        SceCli
Date:          2009.08.13. 12:46:22
Event ID:      1202
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      server.domain.com
Description:
Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Advanced help for this problem is available on http://support.microsoft.com. Query for "troubleshooting 1202 events".

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs) could not be resolved to a SID.  This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights or Restricted Groups branch of a GPO.  To resolve this event, contact an administrator in the domain to perform the following actions:

1.    Identify accounts that could not be resolved to a SID:

From the command prompt, type: FIND /I "Cannot find"  %SYSTEMROOT%\Security\Logs\winlogon.log

The string following "Cannot find" in the FIND output identifies the problem account names.

Example: Cannot find JohnDough.

In this case, the SID for username "JohnDough" could not be determined. This most likely occurs because the account was deleted, renamed, or is spelled differently (e.g. "JohnDoe").

2.    Use RSoP to identify the specific User Rights, Restricted Groups, and Source GPOs that contain the problem accounts:

a.    Start -> Run -> RSoP.msc
b.    Review the results for Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment and Computer Configuration\Windows Settings\Security Settings\Local Policies\Restricted Groups for any errors flagged with a red X.
c.    For any User Right or Restricted Group marked with a red X, the corresponding GPO that contains the problem policy setting is listed under the column entitled "Source GPO". Note the specific User Rights, Restricted Groups and containing Source GPOs that are generating errors.

3.    Remove unresolved accounts from Group Policy

a.    Start -> Run -> MMC.EXE
b.    From the File menu select "Add/Remove Snap-in..."
c.    From the "Add/Remove Snap-in" dialog box select "Add..."
d.    In the "Add Standalone Snap-in" dialog box select "Group Policy" and click "Add"
e.    In the "Select Group Policy Object" dialog box click the "Browse" button.
f.    On the "Browse for a Group Policy Object" dialog box choose the "All" tab
g.    For each source GPO identified in step 2, correct the specific User Rights or Restricted Groups that were flagged with a red X in step 2. These User Rights or Restricted Groups can be corrected by removing or correcting any references to the problem accounts that were identified in step 1.

Advanced help for this problem is available on http://support.microsoft.com. Query for "troubleshooting 1202 events".

При установке компонента OCSP Responder роли Active Directory Certificate Services на контроллере домена создаются следующие локальные учётные записи:

  • OCSPISAPIAppPool
  • DefaultAppPool
  • WdiServiceHost

Этим учётным записям автоматически в Default Domain Controllers Policy в разделе User Rights Assignments выдаются следующие права и привилегии:

User Rights Assignment entry

 Account name

Adjust memory quotas for a process

OCSPISAPIAppPool
DefaultAppPool

Generate security audits

OCSPISAPIAppPool
DefaultAppPool

Profile system performance

WdiServiceHost

Replace a process level token

OCSPISAPIAppPool
DefaultAppPool

Однако, эти учётные записи локальные и контроллер домена неспособен их разрешить в SID, т.к. они не доменные. Для решения этой проблемы нужно задать префикс authority этих учётных записей следующим образом:

User Rights Assignment entry

 Account name

Adjust memory quotas for a process

IIS AppPool\OCSPISAPIAppPool
IIS AppPool\DefaultAppPool

Generate security audits

IIS AppPool\OCSPISAPIAppPool
IIS AppPool\DefaultAppPool

Profile system performance

NT Service\WdiServiceHost

Replace a process level token

IIS AppPool\OCSPISAPIAppPool
IIS AppPool\DefaultAppPool

Примечание: при добавлении этих записей вы должны вписывать эти имена прямо в поле Add user or group, а не использовать Browse и Check names.

Я пока не в курсе причины этой проблемы, но она отправлена на изучение в Windows Server Team, а пока – пользуйтесь этим решением :-)