| ||||
| ||||
| Здравствуйте! Возможно ли, используя КриптоПро OCSP, заменить механизм списков отозванных сертификатов в следующих приложениях: 1. Аутентификация в ОС (MS Windows XP, 2003) 2. SSL-аутентификация (MS IIS, MS ISA) 3. ЭЦП, шифрование электронной почты (MS Outlook 2003) Другими словами, можно ли рассматривать OCSP как полноценную альтернативу CRL в этих приложениях? | ||||
| Ответы: | ||||
| ||||
| Собственно, зависит не только от наличия OCSP, но и от способа использования. Если использовать дополнительно КриптоПро Revocation Provider, то проверка сертификатов на отзыв, при наличии в сертификате расширения AIA - адреса OCSP-службы - будет делаться с использованием OCSP (либо в политике на клиенте должен быть прописан этот адрес). Особенности такие: - OCSP-служба должна быть доступна для пользователей и служб (по http), в т.ч. для не-пользователей домена (в случае винлогона) - сертификат самой OCSP-службы нельзя проверять на отзыв при помощи этой же OCSP-службы - корневой сертификат ЦС должен содержать расширение AIA - адрес OCSP-службы (либо в политике на клиенте должен быть прописан этот адрес) | ||||
| ||||
| Спасибо за ответ! Таким образом, ключевым компонентом является КриптоПро Revocation Provider, который собственно и позволяет использовать ocsp, перехватывая вызовы функции проверки статуса сертификата CryptoAPI. В то же время КриптоПро Revocation Provider работает с OCSP-серверами, например, КриптоПро OCSP сервер, который «ограничен» КриптоПро УЦ и Microsoft CA. Верно ли все вышесказанное и можно ли организовать работу КриптоПро Revocation Provider c другими OCSP-серверами, в частности с различными OCSP-responder коммерческих УЦ? | ||||
| ||||
| Хотел добавить, что КриптоПро OCSP Server может работать в режиме "по CRL", а это значит, что круг УЦ и ЦС, с которорыми он может работать, заметно расширяется. А по поводу совместимости КриптоПро Revocation Provider с различными службами OCSP могу сказать следующее: он реализован в соотвествии с требованиями RFC 2560. Таким образом, если служба OCSP (как, например, нашей разработки) так же соответствует требованиям этого стандарта, то совместимость будет. | ||||
| ||||
| Хотел бы продолжить тему: 1. Для чего нужно указывать адрес ocsp-службы в корневом сертификате? Ведь, когда используются crl, CDP достаточно включить в сертификат пользователя, аналогично, насколько я понимаю, в сертификат пользователя включается AIA, а сертификат ЦС остается без изменений. 2. Как проходит проверка сертификата ocsp-службы? По вашим словам получается, что в этот сертификат нужно включать адрес другой ocsp-службы, а как проверить ее сертификат? Использовать еще одну службу? 3. Скачал и установил дистрибутив RP, административный шаблон отсутствовал в указанной в инструкции директории. Правильно ли я понимаю, что этот шаблон нужно добавить в доменную групповую политику (после установки шаблон был в локальной политике контроллера). 4. Нужно ли изменять политику, если в сертификате содержится адрес ocsp-службы? 5. Возможна ли корректная проверка статуса сертификата с помощью утилиты certutil (у меня не получилось, правда удалось проверить с помощью osputil)? | ||||
| ||||
| 1. Это зависит от конкретных приложений. По идее, проверять статус корневого сертификата не надо. Но кто-то это делает. И еще влияет реакция приложений на невозможность проверить этот статус (может, они вообще игнорируют это). 2. Стандарт предусматривает возможность избежать проверку сертификата службы OCSP на отзыв, включив в него специальное расширение 1.3.6.1.5.5.7.48.1.5 (id-pkix-ocsp-nocheck). 3. Видимо, в документации опечатка. Должно быть: "%WINDIR%\system32\GroupPolicy\Adm". Да, шаблон надо добавить в групповую политицу при необходимости. 4. Нет, адрес службы по умолчанию указывать в групповой политике не нужно, если он указан в расширении AIA сертификатов. Он служит только как дополнительный, если в сертификате адресов слубж нет или по указзанным в нем адресам не удалось получить статус. 5. Вроде бы certutil -verify должен уметь... | ||||
| ||||
| Спасибо, тем не менее certutil –verify работает (winlogon естественно тоже): The revocation function was unable to check revocation for the certificate. 0x80 092012 (-2146885614) ------------------------------------ Revocation check skipped -- no revocation information available Cannot check leaf certificate revocation status Как решить проблему или хотя бы выяснить причину? | ||||
| ||||
| При этом, выполнив последовательность команд: ocsputil.exe makereq -S OCSP.crt.cer new.req ocsputil.exe sendreq new.req new.resp ocsputil.exe respinfo new.resp я получил следующее: Status: 0 Signature algorithm: 1.2.840.113549.1.1.5, 0x0 HasNonce: 1 ProducedAt: 25 мая 2006 14:39:28 Extensions: none Certificates from response: Certificates from response: CN=Online Single responses (1): #1: Hash algorithm: 1.3.14.3.2.26 Serial number: 4D7B 645D DE49 E9F8 CB57 C08E 218D 118D Issuer key hash: C032 2BCC 4A40 33BA 5B9B FED6 288B 1E93 9528 DE36 Issuer name hash: 26FF CA47 A867 BF7F B04E 6220 ED91 776B ED0B 9BCC Certificate status: Good RevTime: none RevReason: none ThisUpdate: 25 мая 2006 14:39:28 NextUpdate: none Archive cutoff: none Extensions: none OCSP's certificate: CN=Online OCSP's certificate is verified. OCSP response is verified. | ||||
| ||||
| Я вам отправил письмо. | ||||
| ||||
| В логе certutil -verify есть ошибка: 2676] 10:00:40.312 ::*0000002* :: WinHttpQueryAuthSchemes(0xea2000, 0x6dd1c, 0x6dd30) [2676] 10:00:40.312 ::*0000002* :: WinHttpQueryAuthSchemes: error 4317 [0x10dd] [2676] 10:00:40.312 ::*0000002* :: WinHttpQueryAuthSchemes() returning FALSE А вот лог ocsputil -sendreq: [3508] cpcspi: Thread: file:line function text xcode(dcode) level: 1 [3508] 12:20:49.578 ::*Session* :: WinHttpCrackUrl("http://192.168.1.1/ocsp.xuda", 0x0, 0x0, 0x12fd74) [3508] 12:20:49.578 ::*Session* :: WinHttpCrackUrlA("http://192.168.1.1/ocsp.xuda", 0x1c, 0x0, 0x12fc40) [3508] 12:20:49.578 ::*Session* :: WinHttpCrackUrlA() returning TRUE [3508] 12:20:49.578 ::*Session* :: WinHttpCrackUrl() returning TRUE [3508] 12:20:49.578 ::*Session* :: WinHttpOpen("Crypto-Pro ocspcli.dll", (1), "", "", 0x0) [3508] 12:20:49.578 ::*Session* :: WinHttpOpen() returning handle 0x11d6000 [3508] 12:20:49.578 ::*Session* :: WinHttpConnect(0x11d6000, "192.168.1.1", 80, 0x0) [3508] 12:20:49.578 ::*Session* :: WinHttpConnect() returning handle 0x11dc000 [3508] 12:20:49.578 ::*Session* :: WinHttpOpenRequest(0x11dc000, "POST", "ocsp.xuda", "", "", 0x0, 0x00000000) [3508] 12:20:49.578 ::*Session* :: WinHttpCreateUrlA(0x12fb1c, 0x0, 0x3980000, 0x12fb58) [3508] 12:20:49.578 ::*Session* :: WinHttpCreateUrlA() returning TRUE [3508] 12:20:49.578 ::*0000001* :: WinHttpOpenRequest() returning handle 0x3970000 [3508] 12:20:49.578 ::*0000001* :: WinHttpSetOption(0x3970000, (77), 0x12fd38 [0x2], 4) [3508] 12:20:49.578 ::*0000001* :: WinHttpSetOption() returning TRUE [3508] 12:20:49.578 ::*0000001* :: WinHttpSendRequest(0x3970000, "Content-type: application/ocsp-request", -1, 0xc75fa0, 248, 248, 0) [3508] 12:20:49.578 ::*0000001* :: sending data: [3508] 12:20:49.578 ::*0000001* :: 416 (0x1a0) bytes [3508] 12:20:49.578 ::*0000001* :: <<<<-------- HTTP headers follow below ----------------------------------------------->>>> [3508] 12:20:49.578 ::*0000001* :: [3508] POST /ocsp.xuda HTTP/1.1 [3508] 12:20:49.578 ::*0000001* :: Content-type: application/ocsp-request [3508] 12:20:49.578 ::*0000001* :: User-Agent: Crypto-Pro ocspcli.dll [3508] 12:20:49.578 ::*0000001* :: [3508] Host: 192.168.1.1 [3508] 12:20:49.578 ::*0000001* :: Content-Length: [3508] 248 [3508] 12:20:49.578 ::*0000001* :: [3508] Connection: Keep-Alive [3508] [3508] 12:20:49.578 ::*0000001* :: <<<<-------- End ----------------------------------------------->>>> [3508] 12:20:49.578 ::*0000001* :: WinHttpSendRequest() returning TRUE [3508] 12:20:49.578 ::*0000001* :: WinHttpReceiveResponse(0x3970000, 0x0) [3508] 12:20:49.656 ::*0000001* :: received data: [3508] 12:20:49.656 ::*0000001* :: 1024 (0x400) bytes [3508] 12:20:49.656 ::*0000001* :: <<<<-------- HTTP headers follow below ----------------------------------------------->>>> [3508] 12:20:49.656 ::*0000001* :: [3508] HTTP/1.1 200 OK [3508] 12:20:49.656 ::*0000001* :: Connection: Keep-Alive [3508] 12:20:49.656 ::*0000001* :: Content-Length: 879 [3508] 12:20:49.656 ::*0000001* :: Date: Fri, 26 May 2006 08:19:17 GMT [3508] 12:20:49.656 ::*0000001* :: [3508] Content-Type: application/ocsp-response [3508] 12:20:49.656 ::*0000001* :: Server: Apache/1.3.26 [3508] (Win32) mod_ssl/2.8.10 SSL-C [3508] [3508] 12:20:49.656 ::*0000001* :: <<<<-------- End ----------------------------------------------->>>> [3508] 12:20:49.656 ::*0000001* :: WinHttpReceiveResponse() returning TRUE [3508] 12:20:49.656 ::*0000001* :: WinHttpQueryHeaders(0x3970000, (0x20000013), "<null>", 0xc75ae0, 0x12fd34 [4], 0x0 [0]) [3508] 12:20:49.656 ::*0000001* :: WinHttpQueryHeaders() returning TRUE [3508] 12:20:49.656 ::*0000001* :: WinHttpReadData(0x3970000, 0x11ec510, 65536, 0x12fd34) [3508] 12:20:49.656 ::*0000001* :: WinHttpReadData() returning TRUE [3508] 12:20:49.656 ::*0000001* :: WinHttpReadData(0x3970000, 0x11ec510, 65536, 0x12fd34) [3508] 12:20:49.656 ::*0000001* :: WinHttpReadData() returning TRUE [3508] 12:20:49.656 ::*0000001* :: WinHttpCloseHandle(0x3970000) [3508] 12:20:49.656 ::*0000001* :: WinHttpCloseHandle() returning TRUE [3508] 12:20:49.656 ::*Session* :: WinHttpCloseHandle(0x11dc000) [3508] 12:20:49.656 ::*Session* :: WinHttpCloseHandle() returning TRUE [3508] 12:20:49.656 ::*Session* :: WinHttpCloseHandle(0x11d6000) [3508] 12:20:49.656 ::*Session* :: WinHttpCloseHandle() returning TRUE [3508] StopTesterThread start Здесь подобных ошибок нет. Не знаете ли вы с чем это может быть связано? | ||||
| ||||
| Посоветуйте что-нибудь, пожалуйста. | ||||
| ||||
| Замечу, что при использовании СОС вход в систему работает. При необходимости могу выслать сертификаты ЦС, клиента и OCSP-службы. | ||||
| ||||
| Еще одно дополнение: при попытке входа в систему с помощью смарт-карты в логах ocsp-службы обращение не фиксируется, в отличие от certutil -verify | ||||
| ||||
| Итак, сообщаю: Условия: 1) Корневой сертификат ЦС не имеет CDP и AIA. 2) Сертификат оператора OCSP не имеет CDP и AIA, но содержит расширение 1.3.6.1.5.5.7.48.1.5 ("Признак доверия службе OCSP") 3) сертификат DC не содержит CDP, но содержит AIA (адрес OCSP-службы) 4) сертификат входа со смарткартой пользователя домена не содержит CDP, но содержит AIA (адрес OCSP-службы) 5) УЦ не в домене, корневой сертификат ЦС установлен в AD в соответствии с рекомендациями, приведёнными в файле "Поддержка КриптоПро Winlogon в КриптоПро УЦ.pdf" (файл входит в http://www.cryptopro.ru/pub/WinLogon/1065/doc.zip) 6) служба OCSP на компьютере не из домена, но доступном по http с компьютеров домена, используется анонимная аутентификация для виртуального каталога OCSP на IIS (по умолчанию) 7) на DC: КриптоПро CSP 3.0 KC2 (лицензия - CSP + TLS server), КриптоПро WL (лицензия - KDC), КриптоПро Revocation Provider (постоянная лицензия) 8) на клиентском компьютере: КриптоПро CSP 3.0 KC1 (лицензия - CSP), КриптоПро WL (лицензия - клиент), КриптоПро Revocation Provider (постоянная лицензия) Итог: винлогон работает, в журнале OCSP-службы при логоне по смарткарте появляются надписи о проверке сертификата клиента и DC. | ||||
Зарипов Тимур