Contents of this directory is archived and no longer updated.

В предыдущей части мы поговорили об основных этапах настройки 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


Share this article:

Comments:

Дмитрий

Спасибо за отличные ГАЙДЫ... Натолкнулся на одно маленькое но... OCSP (часть 2) Есть хитрость от мелкософта oscp работает только на версиях enterprise на стандарте развернуть его не получится так сто господа думайте заренне кто будет внедрять

Денис

Вадимс, ещё раз спасибо. Подняли PKI, используя ваш блог, съэкономив кучу времени и нервов. Хотелось бы уточничь по данной статье. Некоторые моменты рассмотрены кратенько как сами собой разумеющиеся :) (не для всех же...). По абзацу после рис. 1 (fig.1): 1. На последнем шаге при настройке путей проверки CRL'ей мастер подставляет для них пути, а пути для DeltaCRL пустые. Насколько я понимаю принцип заполнения DeltaCRL и CRL, мы должны обязательно указать пути для DeltaCRL? (Если так, то странно, что мастер их не подставил). 2. Каковы в данном случае ваши рекомендации по настройке периода обновления CRL'ей? Оставить значение по-умолчанию "Refresh CRLs based on their validity periods" или задать какое-то другое значение? Спасибо.

Vadims Podāns

> Если так, то странно, что мастер их не подставил а он не может. Мастер пробудет использовать ICertAdmin::GetCAProperty с параметром PropId = CR_PROP_CERTCDPURLS, который показывает ссылки на Base CRL. А PropId, который возвращает ссылки на Delta CRL не существует пока. Поэтому ссылки на Delta CRL надо прописывать самостоятельно. > 2. Каковы в данном случае ваши рекомендации по настройке периода обновления CRL'ей? тут особых рекомендаций нету, наверное.

Comments are closed.