Contents of this directory is archived and no longer updated.

На днях потребовалось поднять ещё один сервер 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). Что примечательно, ничего делать в этой оснастке не надо, достаточно её просто запустить и вы всё сразу увидите:

PKIView 2-tier

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

PKIView Console with OCSP

Если внутри сети особого профита 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

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

URL Retrival Tool

Я на сервере 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. Вот как он выглядит:

 OCSP Client Tool

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

OCSP Client Tool Advanced Settings

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

  • 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 Client Tool results

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

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


Share this article:

Comments:

Anton

Добрый день. У меня наблюдается следующая проблема: OCSP настроен на обновление CRL каждые 5 минут, сертификат отозван, однако вход в системы Vista и Seven с etoken от Алладин и Rutoken осуществляется несмотря на отозванный сертификат. Т.е. создается ощущение, что при логоне просто не проверяется сертификат по протоколу OCSP. Проверка валидности сертификата с помощью certutil проходит успешно(статус сертификата - отозван). Подскажите пожалуйста - в чем может быть проблема(драйверы смарткарты\некорректная настройка OCSP)?

Vadims Podāns

Ок, я зафиксирую этот момент и как только будут новости — отпишусь здесь.

Vadims Podāns

Скажите, а контроллеры домена под какой ОС управляются?

Anton

часть под 2008, часть под 2003. Уровень домена - 2008. Уровень леса - 2000.

Anton

ошибся - уровень домена 2003

Vadims Podāns

Вобщем, если у вас есть контроллеры домена на Wondows 2000 или 2003, то они не могут использовать OCSP, поскольку аутентифицирует не та рабочая станция, на которую логонитесь, а именно контроллер домена. Поэтому в вашем случае работает только CRL и при дефолтных настройках (публикация DeltaCRL раз в сутки) отозванным логонным сертификатом можно пользоваться до суток (на период жизни этого CRL). Поэтому для использования бенефитов OCSP в данном случае вам нужно чтобы все контроллеры были под управлением Windows Server 2008 или 2008 R2.

Comments are closed.