Contents of this directory is archived and no longer updated.

Введение

Сегодня хочу поговорить про OCSPOnline Certificate Status Protocol, который служит для проверки статуса сертификата на предмет отозванности. Как известно, стандартным механизмом проверки статуса сертификата является публикация CRL (Certificate Revocation List). В жизни существует 2 вида CRL:

  • Base CRL – полный список CRL, в котором указываются серийные номера всех отозванных в CA сертификатов и причина отзыва. Поддерживается всеми современными системами Windows. Характеризуется большим объёмом и не очень частой публикацией для уменьшения трафика.
  • Delta CRL – инкрементальный (хотя по факту это скорее дифференциальный) список CRL, в который включаются только сертификаты, которые были отозваны с момента последней публикации полного Base CRL. Характеризуется небольшим объёмом и относительно частой публикацией. Нативно поддерживается только системами не ниже Windows XP. Windows 2000 нативно не умеет его читать, но это становится возможным после применения патча MS04-011.

Опыт использования технологии CRL в широкой массе показал её негативные стороны. Если говорить о Base CRL, то Windows Server 2003/2008 по умолчанию публикуют этот список раз в неделю и в него включаются все сертификаты, которые были выданы и отозваны с момента последнего обновления сертификата CA. Т.к. эти сертификаты как правило выдаются на долгий срок (от 5 до 20 лет), то эти списки со временем могут сильно распухнуть. Из-за этого клиенту для проверки сертификата нужно вытягивать весь Base CRL с CA и искать там требуемый сертификат. Кстати, почему HTTPS сайты частенько тормозят :-) Учитывая, что Base CRL публикуются не очень часто, то для обеспечение наиболее актуального списка CRL была внедрена система Delta CRL, которая включает в себя только сертификаты, которые были отозваны с момента последней публикации Base CRL. По умолчанию CA под управлением Windows Server 2003/2008 публикуют его раз в сутки.

Но это не отменяет необходимости клиенту как скачивать не только Base CRL, но и приходится дополнительно скачивать Delta CRL. Однако Certificate Services в Windows Server 2008 позволяют нам сделать жизнь чуточку лучше и облегчить процесс валидации сертификата за счёт использования OCSP.

Вкратце, OCSP работает очень просто: клиент для проверки статуса сертификата отправляет запрос на OCSP Responder с указанием серийного номера проверяемого сертификата. OCSP Responder на своей стороне проверяет статус сертификата и возвращает этот статус клиенту.

Примечание: использовать протокол OCSP нативно умеют только клиенты под управлением Windows Vista и выше. Предыдущие ОС могут его поддерживать только за счёт сторонних компонентов.

Настройка шаблона CA

Итак, для начала нам потребуется установленный в сети Certification Authority под управлением Windows Server 2008 (любой редакции, кроме Web). По умолчанию с добавлением роли  AD CS добавляется и служба Online Respnder. Для этого так же потребуется установить службы IIS, о чём мастер вам сообщит и предложит сделать. На сервере CA необходимо запустить оснастку Certificate Templates (Start –> Run... –> certtmpl.msc) и там найти шаблон OCSP Response Signing:

OCSP Template fig.1

Данный шаблон характеризуется следующими свойствами:

  • срок действия сертификата составляет 2 недели
  • на вкалдке Request Handlings добавлено право чтения приватного ключа для службы Network Service, поскольку служба OCSP работает от лица Network Service, а не LocalSystem (для LocalSystem отдельных разрешений не требуется)
  • шаблон не содержит CDP и AIA расширений
  • шаблон помечен как неподлежащий для проверки на отзыв (см. fig.1)

На вкладке Security необходимо для учётной записи компьютера, на котором размещён OCSP выдать право Allow Read и Allow Enroll. Это единственное изменение, которое необходимо выполнить для шаблона. Теперь нужно открыть оснастку Certificate Authority и добавить этот шаблон для выдачи:

правой кнопкой на Certificate Templates –> New –> Certificate Template to Issue –> OSCP Response Signing. Далее нужно создать оснастку Certificates для учётной записи компьютера и запросить сертификат на основе этого шаблона с компьютера, где установлен OCSP Responder.

После запроса сертификата не стоит закрывать оснастку Certificates, а выбрать новый сертификат и в All Tasks выбрать Manage Privete keys. В открывшемся окне Permissions выдайте право Read для учётной записи Network Service:

Permissions for OCSP Private Key fig.2

Настройка CA

Следующим этапом нужно подготовить сам CA для работы с OCSP. Для этого вызываем свойства самого CA и переходим на вкладку Extensions:

CA Extensionsfig.3

В списке Extensions выбираем Authority Information Access (AIA), нажимаем Add и в поле вписываем URL для OCSP. В моём случае это http://dc2.contoso.com/ocsp. А так же выставляем нижнюю галочку, чтобы этот путь добавлялся во все издаваемые этим CA сертификаты.

Примечание от 09.08.2009: здесь у меня опечатка на скриншоте - нужно поставить только одну галочку, а именно - только нижнюю. Адрес OCSP не нужно добавлять в AIA издаваемых сертификатов, иначе клиент будет с OCSP адреса пытаться скачать CRT файл.

Примечание: учитвая, что срок действия такого сертификата всего 2 недели, не следует этот шаблон добавлять в Autoenrollment (если используется) Policies, т.к. тут возможны трудности с валидацией сертификата на отрезке времени когда обновляется сертификат CA. Вот как это может выглядеть:

Renewal issuesfig.4

в промежутке t0 – t2 используется старый ключ CA для подписи сертификатов (в том числе и OCSP). В промежутке t1-t3 используется новый сертификат CA. И когда наступает этап t1, когда старый сертификат ещё до истечения срока обновляется на новый, то в промежутке t1-t2 может случиться следующее:

  • клиент отправляет запрос на проверку статуса сертификата Cert1 или Cert2, которые подписаны ключом CA Key 1
  • на сервере CA уже действует новый ключ CA Key 2 и, соответственно, подписанный новым ключом сертификат OCSP
  • сервер подписывает новым ключом OCSP ответ для клиента и пересылает
  • клиент сверяет подписи OCSP и проверяемого сертификата. Подписи не совпадут, т.к. сертификат подписан ключом CA Key 1, а OCSP ответ уже ключом CA Key 2 и откланяет ответ от OCSP Responder, поскольку проверяемый сертификат и сертификат подписи Online Responder должны быть подписаны одним ключом CA.

Чтобы устранить проблему на указанном отрезке времени в Windows Server 2008 включено обновление OCSP Signing сертификатов с использованием существующих ключей. По умолчанию оно не включено, поэтому для активации такого обновления в командной строке следует выполнить:

certutil –setreg ca\UseDefinedCACertInRequest 1

После выполнения этой команды должно получиться нечто похожее на:

C:\Users\administrator>certutil -setreg ca\UseDefinedCACertInRequest 1
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\contoso-DC2-CA\UseDefine
dCACertInRequest:

New Value:
  UseDefinedCACertInRequest REG_DWORD = 1
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Как гласит сообщение, после этой процедуры следует перезапустить службу AD CS:

net stop certsvc
net start certsvc

На сегодня, пожалуй, всё, а в следующий раз продолжим с конфигурированием Online Responder и политики отзыва сертификатов.


Share this article:

Comments:

alexiszp.livejournal.com
alexiszp.livejournal.com 07.04.2010 15:39 (GMT+3) OCSP (часть 1)

Добрый день! Пара вопросов: 1."В списке Extensions выбираем Authority Information Access (AIA), нажимаем Add и в поле вписываем URL для OCSP." При нажатии на ADD предлагается к выбору несколько переменных, я так понимаю, что если Вы не уточнили, то мы оставляем переменную по умолчанию(CaName) ? 2. И немного ниже "Примечание от 09.08.2009: здесь у меня опечатка - нужно поставить только одну галочку, а именно - только нижнюю." Но на картинке галочки стоят обе, возникает вопрос что правильнее - примечание или картинка ? Спасибо за помощь!

Vadims Podāns
Vadims Podāns 07.04.2010 15:59 (GMT+3) OCSP (часть 1)

1) там вы указываете HTTP адрес OCSP респондера. Как вы его укажете, с помощью переменных или абосолютного пути — всё равно. Учитывая, что OCSP по хорошему следует размещать на веб-сервере, а не на CA. 2) примечание правильное. Картинка неправильная. Я сегодня постараюсь заменить картинку на правильную.

Emulty
Emulty 15.02.2011 15:30 (GMT+3) OCSP (часть 1)

Огромная благодарность за данное руководство.

Mikhail
Mikhail 15.07.2011 10:38 (GMT+3) OCSP (часть 1)

> Далее нужно создать оснастку Certificates для учётной записи компьютера и запросить сертификат на основе этого шаблона с компьютера, где установлен OCSP Responder. Пожалуйста перепроверьте это утверждение. После выполнения второй части инструкции "настройка Online Responder", в СА запрашивается еще один OCSP сертификат. Спрашивается, зачем нужен был первый? PS Win2008R2Ent

Vadims Podāns
Vadims Podāns 15.07.2011 10:39 (GMT+3) OCSP (часть 1)

Первый нужен, чтобы выдать разрешение на закрытый ключ. Это разрешение будет наследоваться на последующие сертификаты OCSP.

Mikhail
Mikhail 15.07.2011 11:31 (GMT+3) OCSP (часть 1)

Простите чайника, хочется уточнить. Правильно ли я Вас понял, на реальном примере. Первый сертификат, создаваемый по инструкции из первой части статьи, как сертификат компьютера получил у меня серийный номер 61 18 5f 90 00 00 00 00 00 02. Второй сертификат, создаваемый автоматически по инструкции из второй части статьи, как сертификат сервиса Online Responder Service, получил номер 61 18 5f 90 00 00 00 00 00 03. Получается, автоматически созданный сертификат получит права ДРУГОГО сертификата?! У них же общего, SN, шаблон да издатель. При этом у них разные владельцы (компьютер и сервис соответственно). Нет, я конечно понимаю, что от MS можно ждать многого, но настолько... В голове не укладывается. Кроме того, сервис Online Responder Service запускается от имени Network Service, соответственно Network Service, как владелец, в любом случае должен получить права на доступ к секретной части ключа.

Vadims Podāns
Vadims Podāns 15.07.2011 11:41 (GMT+3) OCSP (часть 1)

вы не совсем правы. У них есть одно общее — второй сертификат является обновлением первого сертификата. Вот на этом основании разрешения на закрытый ключ наследуются. В противном случае вам пришлось бы каждый раз переназначать разрешения на закрытый ключ при обновлении сертификата OCSP.

Mikhail
Mikhail 15.07.2011 20:18 (GMT+3) OCSP (часть 1)

Спасибо Вам еще раз! Нашел в справке. Пришлось даже русскую локаль доставить для теста. Уж больно неожиданной была рекомендация предварительного получения OCSP сертификата, которой я больше нигде не успел встретить :) --- Цитата из справки Win2008R2 Rus --- Для выбора сертификата подписи конфигурации отзыва доступны следующие параметры. Параметр по умолчанию Автоматически выбрать сертификат подписи в общем случае удовлетворяет большинству потребностей организаций. Этот параметр позволяет процессу настройки конфигурации отзыва определить подходящий сертификат подписи в локальном хранилище сертификатов. Однако если также включен режим автоматической подачи заявки на сертификат подписи, то служба «Сетевой ответчик» подаст заявку и будет использовать полученный сертификат подписи. --- Но вот зачем именно руками давать права для Network Service на чтение приватного ключа, пока все еще не ясно. Ощущение, как будто и Вы и MS считаете это аксиомой, недостойной объяснения :)

Vadims Podāns
Vadims Podāns 15.07.2011 21:03 (GMT+3) OCSP (часть 1)

Потому что сама служба OCSP Responder использует учётную запись Network Service для своей работы. А по умолчанию служба Network Service не имеет прав на чтение закрытых ключей сертификатов, установленных в компьютерном хранилище. Именно поэтому и нужно назначить права отдельно.

Бехзод
Бехзод 28.03.2013 16:20 (GMT+3) OCSP (часть 1)

А как настроить OCSP, чтобы можно было проверять статус сертификата через интернет?

Comments are closed.