Contents of this directory is archived and no longer updated.

Posts on this page:

Disclaimer: данный материал публикуется только для ознакомительных целей и не рекомендуется для использования в реальной производственной среде.

Краткий ввод в курс дела. Что такое EV сертификат – это Extended Validation сертификат, который в браузере отображается зелёной полосой:

Extended Validation certificate in Internet Explorer 7 or higher

Что это означает? Это означает, что издатель сертификата (например, VeriSign) более серьёзно и внимательно изучил предъявителя этого сертификата, что даёт пользователям ещё большую гарантию, что сайт, на который вы попали, является тем самым сайтом, который вы набрали в адресной строке. А так же этим подтверждается, что сайт является зарегистрированной коммерческой организацией с сопутствующими проверками. Т.е. к получателю Extended Validation сертификатов предъявляются достаточно жёсткие требования. Эти сертификаты в Public Certification Authorities стоят значимо дороже, чем обычные SSL сертификаты (я посмотрел по предложениям и получилось в среднем увеличение цены в 2 раза). Плюс, такие сертификаты не имеют возможности использования WildCard доменов в Subject, хотя допускают Subject Alternative Names (когда одному web-сайту сопоставляется несколько имён). Такие сертификаты в интернете могут выпускать только одобренные центры сертификации (Certification Authorities). Список таких CA можно посмотреть вот здесь: http://cabforum.org/forum.html. Требования к работе с такими сертификатами для CA и покупателей: http://cabforum.org/documents.html

Но это всё лирика. Мы хотим внутри корпоративного домена поднять SSL веб-портал и чтобы там была такая же зелёная полоска :-) и мы можем такое сделать. Я покажу процесс на примере CA и домена под управлением Windows Server 2008 R2. Я предполагаю, что у вас уже развёрнут домен Active Directory и установлена роль AD CS (Active Directory Certificate Services).

Когда у нас предварительные подготовления закончены нам нужно произвести необходимые изменения в шаблоне Web Server. Для этого нужно сделать следующее:

  1. на сервере с установленным CA запустить оснастку Certificate Templates: certtmpl.msc
  2. выбрать шаблон Web Server и правой кнопкой выбрать Duplicate Certificate и выбрать версию шаблона 2 или 3 (Windows Server 2003 Enterprise Edition или Windows Server 2008 Enterprise Edition, соответственно).
  3. В поле Template Display Name напишите новое имя шаблону (например, Web Server V2 или V3).
  4. Убедитесь, что срок действия сертификатов на основе этого шаблона установлен 1 год (обычно для SSL веб-сайтов не выдают сертификаты на срок больше 1 года).
  5. На вкладке Extensions выберите Issuance Policies –> Edit –> Add –> New:
     Editing Issuance Policy
    и скопируйте сгенерированный OID в поле Object Identifier, он нам ещё потребуется.
  6. Напишите название вашей политики и адрес CPS (Certificate Practice Statement).
  7. На вкладке Request Handling настройте свои значения (как экспорт закрытого ключа, архивация закрытого ключа) на своё усмотрение.
  8. На вкладке Issuance Requirements поставьте ручное одобрение администратора CA (чтобы контролировать расход EV сертификатов :-), либо на вкладке Security отрегулируйте разрешения, кому можно запрашивать сертификат.
  9. Сохраните шаблон.

Теперь раскройте оснастку Certificate Authority и перейдите в Certificate Templates –> New –> Template To Issue и выберите наш новый шаблон. После того, как все приготовления закончены, можно приступать к редактированию групповой политики.

Примечание: Для редактирования политики вам потребуется консоль GPMC в Windows Server 2008 R2, Windows 7 с установленным RSAT. При этом версия ОС на контроллере может быть другой, но не ниже Windows Server 2003, а сервер CA не ниже Windows Server 2003 Enterprise Edition.

Запустите оснастку GPMC и создайте новую политику, которая будет прилинкована на уровне домена. Безусловно, вы можете редактировать существующую Default Domain Policy, но я не рекомендую использовать дефолтную политику, а для каждой задачи создавать свою политику и линковать куда нужно. В редакторе политики перейдите по секции:

Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities

здесь выберите All Task –> Import и импортируйте корневой сертификат вашего CA, который является корневым в вашем лесу. Далее, выберите свойства сертификата (не открывать сам сертификат) и перейдите в таб Extended Validation:

Edit Extended Validation tab

И добавьте сюда тот самый OID, который у вас был сгенерирован при создании новой Issuance Policy.

Теперь вам нужно перейти на ваш web-сервер. Если это Windows Server 2003, то вы можете запросить новый SSL сертификат из оснастки IIS. Если у вас web-сервер под управлением Windows Server 2008 или выше, то вы не можете больше запрашивать SSL сертификат из оснастки IIS, а только путём генерирования запроса в формате PKCS#7, либо через MMC оснастку Certificates запущенной от лица Local Computer. Запросите новый сертификат на основе вновь созданного шаблона (желательно при запросе указывать наиболее подробные сведения о вашем Web-сервере). Если у вас в политике шаблона указано ручное одобрение запроса – одобрите его в оснастке Certification Authority –> Pending Requests. После того, как сертификат сгенерирован, настройте ваш веб-сервер на работу с SSL с использованием этого сертификата.

Теперь подождите, пока отредактированная групповая политика применится на компьютерах домена. После чего запустите браузер на любом клиенте (не ниже Windows XP SP2 с установленным Internet Explorer 7 или выше) и наберите HTTPS адрес вашего веб-сервера и получайте профит:

 Extended Validation certificate in Internet Explorer 7 or higher

Extended Validation certificate in Internet Explorer 7 or higher

И ещё раз о требованиях к операционным системам:

  • Domain Controller – не ниже Windows Server 2003 Standard Edition. Для редактирования политики потребуется Windows 7 с RSAT или рядовой член домена под управлением Windows Server 2008 R2 с установленным компонентом Group Policy Management.
  • CA – не ниже Windows Server 2003 Enteprise Edition (Кроме Windows Server 2003/2008 Standard/Web Edition).
  • веб-сервер – любой.
  • клиентский компьютер – не ниже Windows XP SP2 и с установленным Internet Explorer не ниже 7 версии.

И ещё раз напоминаю, что это будет видно только тем компьютерам, которые получили изменённую политику. Остальные компьютеры будут видеть обычный замочек и всё.

Have a nice day!

Это будет краткая заметка по решению одной проблемы (пока причина проблемы не установлена) при установке 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, а пока – пользуйтесь этим решением :-)

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

В предыдущей части мы поговорили об основных этапах настройки OCSP на сервере CA. Науонец-то мне удалось восстановить работу виртуальных машин и можно продолжить разговор. И сейчас предлагаю поговорить уже о базовой настройке OCSP Responder.

настройка Online Responder

Настройка Online Responder очень проста: Start –> Administrative Tools –> Online Responder Management. И правой кнопкой по Revocation Configuration –> Add Revocation Configuration. Мастер очень простой и понятный, интересно будет на стадии Select Signing Certificate:

Select Signing Certificate fig.1

именно тут нужно ставить галочку Auto-Enroll for an OCSP signing certificate, вместо использования Certificate Autoenrollment. С этой галочкой OCSP будет для себя каждые две недели (по умолчанию) запрашивать новый сертификат. В последнем шаге указываются адреса CRL'ов, по которым OCSP будет сверять сертификаты, а так же период обновления CRL'ов. После этой несложной процедуры, нужно этот сервер указать как Array Controller. Дело в том, что в сети может быть несколько онлайн респондеров для одного CA и они будут образовывать массив респондеров. Но один из них должен стать главным в массиве и остальные члены этого массива будут сверять свою конфигурацию именно с контроллером. Для этого в той же оснастке нужно перейти в Array Configuration, правой кнопкой на вновь созданном сервере и выбрать Set As Array Controller.

Проверка конфигурации

В принципе, теперь можно проверять конфигурацию OCSP. Если встать в самый верх дерева консоли (Online Responer: servername), то в центральной части оснастки должна появиться зелёная галочка:

Test OCSP Configurationfig.2

и в списке Array Members выделяя каждый сервер внизу должны увидеть сообщение о том, что член массива имеет рабочую конфигурацию и действительный сертификат:

Test OCSP Configuration fig.3

 

Там же вы можете посмотреть сам сертификат, который будет использоваться для подписи OCSP ответов. Если ваша картина соответствует тому, что отображено на скриншотах, то это значит, что вы успешно настроили OCSP. Теперь все издаваемые сертификаты в поле Authority Information Access будут содержать адрес OCSP респондера и клиенты Windows Vista и выше смогут через него проверять статус сертификата. Собственно, как это выглядит:

Certificate with AIA 
fig.4

Как видите, там прописан адрес, куда будут направляться OCSP запросы. В качестве бонуса прилагаю трассировку Network Monitor ответа OCSP Responder:

  Frame: Number = 10, Captured Frame Length = 2974, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-01-02-05],SourceAddress:[00-15-5D-01-02-01]
+ Ipv4: Src = 192.168.2.11, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 11241, Total IP Length = 2960
+ Tcp: Flags=...A...., SrcPort=HTTPS(443), DstPort=49800, PayloadLen=2920, Seq=2068515486 - 2068518406, Ack=1096717416, Win=513 (scale factor 0x8) = 131328
- Ssl:   Server Hello. Certificate. Certificate Status.
  - TlsRecordLayer:
     ContentType: HandShake
   + Version: TLS 1.0
     Length: 4139 (0x102B)
   - SSLHandshake: SSL HandShake TLS 1.0 Encrypted Handshake Message
      HandShakeType: ServerHello(0x02)
      Length: 76 (0x4C)
    + ServerHello: 0x1
      HandShakeType: Certificate(0x0B)
      Length: 2556 (0x9FC)
    - Cert: 0x1
       CertOffset: 2553 (0x9F9)
     - Certificates:
        CertificateLength: 1088 (0x440)
      - X509Cert: Issuer: contoso-DC2-CA,contoso,com, Subject: dc2.contoso.com,OU,Contoso,Riga,Riga,LV
       + SequenceHeader:
       - TbsCertificate: Issuer: contoso-DC2-CA,contoso,com, Subject: dc2.contoso.com,OU,Contoso,Riga,Riga,LV
        + SequenceHeader:
        + Tag0:
        + Version: v3 (2)
        + SerialNumber: 0x110c0b52000000000013
        + Signature: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)
        + Issuer: contoso-DC2-CA,contoso,com
        + Validity: From: 05/11/09 17:24:32 UTC To: 03/30/11 14:06:53 UTC
        + Subject: dc2.contoso.com,OU,Contoso,Riga,Riga,LV
        + SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)
        + Tag3:
        + Extensions:
       + SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)
       + Signature:
     - Certificates:
        CertificateLength: 1459 (0x5B3)
      + X509Cert: Issuer: Contoso CA,contoso,com, Subject: contoso-DC2-CA,contoso,com
      HandShakeType: Certificate Status(0x16)
      Length: 1491 (0x5D3)
    - CertStatus: 0x1
       CertificateStatusType: OCSP Response(0x01)
     - OcspResponse:
        OCSPResponseLength: 1487 (0x5CF)
      + OCSPResponseData: Response has valid confirmations (0); Cert Status = Good; SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

Если смотреть в Network Monitor, то запрос клиента в графе протокол будет - SSL, а в графе Description – SSL:  Client Hello. В ответе OCSP в графе Description будет – SSL:  Server Hello. Certificate. Certificate Status. Эту часть я выделил синим цветом в начале трассировки. Далее, красным я выделил часть, в которой содержится полная информация о проверяемом сертификате. Чуть ниже синим выделил часть, которая содержит всю необходимую информацию о сертификате издателя для проверяемого сертификата (там по сути будет та же информация, что и в красной части, поэтому свёрнуто). Но наиболее полезным для нас будет именно часть, которая выделена зелёным цветом, поскольку именно там будет храниться ответ OCSP. В данном случае сертификат имеет статус Good, т.е. валидный. В противном случае там будет отображено следующее:

+ OCSPResponseData: Response has valid confirmations (0); Cert Status = Revoked; SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

я отозвал сертификат, опубликовал Delta CRL и снова промониторил трафик. Браузер, в свою очередь, вежливо предложил покинуть этот сомнительный ресурс.

Заключение

Как мы успели рассмотреть, конфигурирование OCSP в Windows Server 2008 достаточно простое, хотя и требует от администраторов определённых навыков и умений. Зато в ответ мы получаем достаточно простую схему проверки сертификатов без необходимости скачивания каждый раз списков CRL. Безусловно, я не ставил перед собой задачу полного раскрытия всех аспектов конфигурирования OCSP (читай, срывания покровов), но показать основные ключевые этапы, которые придётся пройти каждому, кто будет настраивать OCSP в своих сетях. Поэтому в конце прилагаю несколько ссылок на более полное и глубокое исследование этого вопроса:

Setting Up Online Responder Services in a Network
Online Responder Installation, Configuration, and Troubleshooting Guide

Введение

Сегодня хочу поговорить про 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 и политики отзыва сертификатов.