OCSP_BASIC_RESPONSE_INFO structure (wincrypt.h)

The OCSP_BASIC_RESPONSE_INFO structure contains a basic online certificate status protocol (OCSP) response as specified by RFC 2560. The RFC specifies that a single response can contain a sequence of certificates for which statuses are provided. The rgResponseEntry member of this structure contains an OCSP_BASIC_RESPONSE_ENTRY structure for each certificate in a sequence.

Syntax

Members

A value that indicates the protocol version of the response.

OCSP_BASIC_RESPONSE_V1 (0)

A value that indicates the type of ID the responder used in this response.

OCSP_BASIC_BY_NAME_RESPONDER_ID (1)

OCSP_BASIC_BY_KEY_RESPONDER_ID (2)

A CERT_NAME_BLOB structure that contains the subject name of the responder signing certificate.

A CRYPT_HASH_BLOB that contains a hash of the responder signing certificate public key.

The date and time at which the response was signed.

The number of elements in the rgResponseEntry array.

An array of pointers to OCSP_BASIC_RESPONSE_ENTRY structures, each of which contains a certificate status.

The number of elements in the rgExtension array.

An array of pointers to CERT_EXTENSION structures, each of which contains additional information about the response.

Remarks

OCSP responder applications encode this structure and store it in an OCSP_BASIC_SIGNED_RESPONSE_INFO ToBeSigned member. Conversely, OCSP client applications decode the OCSP_BASIC_SIGNED_RESPONSE_INFO structure to obtain this structure.

OCSP applications can encode or decode this structure by using X509_ASN_ENCODING or PKCS_7_ASN_ENCODING.

Введение

Сегодня хочу поговорить про OCSP – Online 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:

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

• срок действия сертификата составляет 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:

Настройка CA

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

В списке 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. Вот как это может выглядеть:

в промежутке 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 и политики отзыва сертификатов.

What is ocsp in windows

КриптоПро TSP Client и КриптоПро OCSP Client не имеют отдельных дистрибутивов для установки.

Чтобы установить КриптоПро TSP Client или КриптоПро OCSP Client неоходимо установить тот программный продукт, в состав которого входит КриптоПро TSP Client или КриптоПро OCSP Client.

КриптоПро TSP Client входит в состав:

1. TSPCOM
2. TSPUTIL — 64-х/32-х битные системы
3. КриптоПро ЭЦП runtime (также будет установлен OCSP Client) — 64-х/32-х битные системы
4. КриптоПро CADESCOM (также будет установлен OCSP Client) — 64-х/32-х битные системы
5. КриптоПро ЭЦП Browser plug-in (также будет установлен OCSP Client)

КриптоПро OCSP Client входит в состав:

1. OCSPCOM
2. OCSPUTIL — 64-х/32-х битные системы
3. КриптоПро ЭЦП runtime (также будет установлен TSP Client) — 64-х/32-х битные системы
4. КриптоПро CADESCOM (также будет установлен TSP Client) — 64-х/32-х битные системы
5. КриптоПро ЭЦП Browser plug-in (также будет установлен TSP Client)

КриптоПро TSP Client 2.0 входит в состав:

1. TSPCOM 2.0
2. TSPUTIL 2.0 — 64-х/32-х битные системы
3. КриптоПро ЭЦП runtime 2.0 (также будет установлен OCSP Client 2.0) — 64-х/32-х битные системы
4. КриптоПро CADESCOM 2.0 (также будет установлен OCSP Client 2.0) — 64-х/32-х битные системы
5. КриптоПро ЭЦП Browser plug-in (также будет установлен OCSP Client 2.0)

КриптоПро OCSP Client 2.0 входит в состав:

OCSP_RESPONSE_INFO structure (wincrypt.h)

The OCSP_RESPONSE_INFO structure indicates the success or failure of the corresponding online certificate status protocol (OCSP) request. For successful requests, it contains the type and value of response information.

Syntax

Members

A value that indicates the processing status of the corresponding request. If the status is anything other than OCSP_SUCCESSFUL_RESPONSE, pszObjId and Value are not set.

This member can be one of the following possible values.

Value	Meaning
OCSP_SUCCESSFUL_RESPONSE 0	The response has valid confirmations.
OCSP_MALFORMED_REQUEST_RESPONSE 1	The request received does not conform to OCSP syntax.
OCSP_INTERNAL_ERROR_RESPONSE 2	The responder encountered an internal error. The request should be resent to a different responder.
OCSP_TRY_LATER_RESPONSE 3	The responder service is operational but temporarily unable to respond.
4	This value is not used.
OCSP_SIG_REQUIRED_RESPONSE 5	Before the responder service can respond, it requires that the client sign the request.
OCSP_UNAUTHORIZED_RESPONSE 6	The client is not authorized to request a response from this responder service.

A pointer to a string that identifies the type of data in Value.

The following table lists possible values for pszObjId.

Value	Meaning
szOID_PKIX_OCSP_BASIC_SIGNED_RESPONSE	1.3.6.1.5.5.7.48.1.1

An array of bytes that contain data encoded by using Distinguished Encoding Rules (DER), as specified by pszObjId.

Remarks

OCSP applications can encode or decode this structure by using X509_ASN_ENCODING or PKCS_7_ASN_ENCODING.

What is the algorithm used by windows for certificate revokation (OCSP or CRL) and how to configure them?

I’m using c# .Net framework for connecting to an HTTPS service and want to know how does windows check the certificate revokation. I’ve googled for hours and find that windows supports both OCSP and CRL. But the question is which one is used exactly? Is there any way to configure the used algorithm globally on the OS or from code (without using any third party library)?

Any help is appreciated.

2 Answers 2

The default behavior is:

• If OCSP is configured in certificate, OCSP is used.
• If OCSP fails, CRL is attempted.
• If CRL fails, a RevocationOffline error is raised. Application decides how to react to this error.

This was a very-very simple explanation. For better understanding of how revocation checking in Windows works, I would suggest to read these articles:

It generally depends on the certificate issuer as to what mechanism it supports . However if your application is trusting any certificate then certificate revocation should to be checked and I will suggest to use OCSP . Some drawbacks of CRL are outlined below

• CRL Can create a large amount of overhead, as the client has to search through the revocation list. In some cases this can be 1000’s of lines long.
• CRLs are updated periodically every 5-14 days. Potentially leaving the attack surface open until the next CRL update.
• generally speaking If the client is unable to download the CRL then by default the client will trust the certificate. This is true for most of the popular browser applications.