Ссылки на другие материалы из этой серии:

• Устанавливаем Certification Authority — Подведение итогов

В предыдущей части (Устанавливаем 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"

:: Включаем DiscreteSignatureAlgorithm
Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 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 настраивается следующим образом:

• OCSP (часть 1)
• OCSP (часть 2)

Примечание: пост-установочный скрипт уже сконфигурировал расширение 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. И вот что вы должны увидеть в конечном итоге:

Results

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

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

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

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

(для скачивания файла нажмите на кнопку правой кнопкой и выберите 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

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

• OCSP (часть 1)
• OCSP (часть 2)
• Certificate Chaining Engine — как это работает
• CRL Distribution Points и Authority Information Access
• Certificate chaining engine (CCE) и отзыв корневых сертификатов
• OCSP или CRL?

Этим постом я начинаю серию небольших заметок по не всегда очевидным фактам в 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 выдаются следующие права и привилегии:

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

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

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

На днях потребовалось поднять ещё один сервер CA на Windows Server 2008 R2 и на нём же OCSP респондер. Я уже писал про установку OCSP Responder в Windows Server 2008:

• OCSP (часть 1)
• OCSP (часть 2)

В принципе, настройка достаточно простая. Но мы обязаны периодически проверять работу этой службы и служб проверки статуса сертификата в целом. Для задач проверки работоспособности служб отзыва сертификатов у нас есть несколько решений, которые поставляются вместе с Windows, а так же инструменты сторонних разработчиков. Предлагаю вашему вниманию несколько таких инструментов.

PKIView.msc

Это стандартная MMC оснастка, которая устанавливается в систему с установкой роли Active Directory Certificates Services (для Windows Server 2008/R2) или с установкой Resource Kit (для Windows Server 2003). Что примечательно, ничего делать в этой оснастке не надо, достаточно её просто запустить и вы всё сразу увидите:

Данная оснастка собирает полную PKI иерархию в лесу (в моём случае это двухуровневая иерархия CA), считывает с них CDP и AIA списки и проверяет доступность сертификатов CA и списков CRL. Я специально удалил с сервера Base CRL список. И об этом мы бы узнали, скорее всего, только когда клиент не смог бы подключиться к SSL/TLS/IPSec ресурсу. А так – мы можем в любой момент проверить все CDP и AIA каждого сервера CA. И вот примерный образец, как должны выглядеть CDP и AIA для CA, который обслуживает клиентов из внешней сети:

Если внутри сети особого профита OCSP не получите, то для интернета он будет как нельзя кстати. Ну и для клиентов из интернета ваши LDAP пути для CRL никакого интереса не будут представлять. Т.е. мы имем классические CRL’ы и OCSP респондер. Собственно, статус Ok нам говорит, что с ним всё в порядке. Вы можете прямо из этой консоли выбрать правой кнопкой каждый пункт и посмотреть фактическое содержимое каждого CRL списка или CRT файла (CRT файлы в AIA требуются нам для построения цепочки сертификатов, т.н. certificate chain). Однако в отношении с OCSP мы видим только общую работоспособность респондера. Так же общую работоспособность можно проверить через оснастку Online Responder Mangement на каждом OCSP сервере. Но это всё на стороне сервера. А вот продиагностировать клиента (убедиться, что клиент работает в первую очередь с OCSP, а не с классическими CRL списками) здесь не получится и этому будет посвящена следующая часть этой статьи.

Certutil

Всем известная утилита Certutil.exe, которая поставляется не только с серверными операционными системами, но и с клиентскими тоже. К слову сказать, по сложности синтаксиса и богатством функционала с certutil.exe тягаться может разве что netsh.exe . К сожалению я не смог найти этой информации во встроенной справки certutil, поэтому пришлось искать альтернативные источники этой информации.

Итак, если мы хотим проверить работоспособность клиентского компьютера (напомню, что из клиентских ОС работать с OCSP могут только Windows Vista и выше), то нужно сначала экспортировать произвольный сертификат, который выдал проверяемый сервер CA в файл. После этого в командной строке набрать следующую команду:

certutil –url path\certificate.cer

и откроется следующее окно:

Я на сервере CA отозвал один сертификат и решил проверить, что мне на это скажет OCSP. Для этого в правой части выбираем, что хотим проверить статус сертификата с использованием только OCSP и нажимаем кнопку Retrieve. И в верхнем окне мы видим адрес OCSP сервера и статус проверямого сертификата. Как видите, он отозван. Администраторам PKI следует знать о богатейшем функционале certutil не только в теории, но и в практике тоже.

Кстати говоря, я себе сделал контекстное меню для .CER и .DER файлов, по которому вызывается эта утилита и можно будет сразу не отходя от кассы проверить сертификат или CDP/AIA того CA, который издал этот сертификат. Вот как выглядит .reg файл:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CERFile\shell\Check Certificate Revocation Status]

[HKEY_CLASSES_ROOT\CERFile\shell\Check Certificate Revocation Status\command]
@="certutil -url \"%1\""

Ascertia OCSP Client Tool

Когда вы PKI занимаетесь на достаточно серьёзном уровне, тогда приходят более другие инструменты цена у которых отлична от нуля и которые являются уже Enterprise инструментами, либо у вас клиент работает под ОС, которая не поддерживает OCSP (все ОС до Windows Vista). Один из таких инструментов – OCSP Client Tool от Ascertia. Вот как он выглядит:

Как видите, интерфейс достаточно простой, но в нём уже видны некоторые возможности. Это возможность проверки множества сертификатов в пределах одного запроса. Это означает, что каждый сертификат не будет проверяться отдельным запросом, а все Serial ID сертификатов (в пределах одинакового издателя) будут помещены в один OCSP запрос и OCSP так же одним ответом выдаст статус по каждому сертификату. Т.е. запросов будет ровно столько, сколько различных издателей присуствует в этом окне. Также возможно вместо индивидуального добавления сертификата добавлять цепочку сертификатов (certificate chain) в формате PKCS#7. Плюс, так же можно указать какой-то один OCSP респондер явно (ведь он может работать с несколькими CA), либо руководствоваться информацией об адресе OCSP респондера из поля AIA каждого сертификата. И ещё можно подписать сам запрос. Но нас больше будет интересовать, что именно мы можем проверить:

Мы можем проверить работу следующих компонентов:

• Nonce extension – это особый тип запроса, в который включается как ID проверяемого сертификата, так и уникальный номер запроса. OCSP респондер должен ответить клиенту сообщением, которое включает этот уникальный номер запроса. Плюс, это заставляет OCSP респондер игнорировать свой кеш, а выполнять полную сверку с CRL. По умолчанию в Windows-реализации OCSP Responder, такие запросы не поддерживаются, поскольку Windows-клиенты никогда не используют Nonce. Но вы можете включить поддержку таких запросов в консоли OCSP Responder.
• Add Service Locator extension – используется для извлечения AIA расширения и включения его в специальное поле запроса Service Locator.
• Check all certificates in PKCS#7 – при добавлении в основное окно не индвивидуальные сертификаты, а цепочку сертификатов, то эта опция разберёт эту цепочку на уникальные сертификаты.
• Verify signature on OCSP response – будет произведена проверка цифровой подписи OCSP-ответа с построением пути для этого сертификата до корневого CA.
• Сheck OCSP Responder authority to respond to CA – проверяется, что сертификат OCSP, которым подписан OCSP-ответ выдан тем же CA, которым выдан сам проверяемый сертификат. Этим проверяется, что OCSP респондер авторизован для конкретного CA для сообщения сведений о статусе сертификатов. Так же проверяется, что в EKU этого сертификата указано OCSP Signing.

Собственно и все основные настройки. Теперь нажимаем в основном окне Send Request и получаем много профита:

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

надеюсь, этот пост поможет вам подружиться с безусловно хорошей вещью, как OCSP Responder и научиться проверять его и работу сопутствующих компонентов