На днях потребовалось поднять ещё один сервер CA на Windows Server 2008 R2 и на нём же OCSP респондер. Я уже писал про установку OCSP Responder в Windows Server 2008:
В принципе, настройка достаточно простая. Но мы обязаны периодически проверять работу этой службы и служб проверки статуса сертификата в целом. Для задач проверки работоспособности служб отзыва сертификатов у нас есть несколько решений, которые поставляются вместе с 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 и научиться проверять его и работу сопутствующих компонентов