Я подозреваю что процесс построения кеша CRL может вызвать задержку в некоторых приложениях.
У нас есть несколько приложений .NET, которые иногда «работают медленно» без доступа к процессору или диску. Подозреваю, что они зависают на аутентификации при попытке проверить сертификат, так как тайм-аут составляет почти 20 секунд.
Согласно эта статья MSFT
Большинство приложений не указывают CryptoAPI на использование совокупного тайм-аута. Если опция совокупного тайм-аута не включена, CryptoAPI использует настройку CryptoAPI по умолчанию, которая составляет 15 секунд для каждого URL. Если кумулятивная опция тайм-аута указана приложением, тогда CryptoAPI будет использовать настройку по умолчанию 20 секунд в качестве совокупного тайм-аута. Максимальный тайм-аут первого URL-адреса составляет 10 секунд. Каждый последующий тайм-аут URL составляет половину оставшегося баланса в совокупном значении тайм-аута.
Поскольку это служба, как я могу обнаружить и зарегистрировать зависания CryptoAPI для приложений, для которых у меня есть исходный код, а также для сторонних разработчиков?
У меня есть несколько различных вариантов, поскольку устранение неполадок с потенциальной PKI может быть сложной проблемой.
CRL - медленные, громоздкие звери ...
Прежде всего, я собираюсь сказать вам, что тайм-ауты CRL привели к тому, что самая большая PKI в мире не использует CRL для подавляющего большинства потребностей проверки PKI. Загрузка файла размером 50 МБ, когда пользователю просто нужно дать или нет перед отправкой зашифрованного электронного письма, не стоит начинать!
Как сделать валидацию
1. Вы можете протестировать замену собственного клиента проверки Microsoft с помощью стороннего клиента проверки, такого как Tumbleweed или другие, а затем контролировать сторонний клиент проверки (в качестве элемента управления). Tumbleweed / Axways продает и предоставляет пробные версии популярного стороннего проверочного клиента, ретрансляторов и респондентов OCSP. Вы также можете использовать OpenSSL, ejbca или OpenCA в качестве респондентов проверки. Кроме того, существует платформа PKIF OSS, которая включает в себя определенные функции ведения журнала CAPI, и клиенты OCSP, расположенные по адресу http://pkif.sourceforge.net/
2 - Вы можете контролировать источники данных проверки (CRL, OCSP, SCVP).
3 - Другим источником проблем может быть медленное разрешение DNS, отсутствие кэширования DNS или неверно настроенная PKI, отсутствие доверительных отношений или время, необходимое для обновления CRL (вызывающее временное зависание, если PKI большего размера).
Не могли бы вы поделиться более подробной информацией о конфигурации приложений, самой PKI, полях для сертификатов x509, пропускной способности и т. Д. В частности, меня интересуют поля, относящиеся к проверке, такие как поле доступа к информации о полномочиях (AIA) для пример и любые жестко заданные ссылки на CRL или OCSP.
Имейте в виду, что в типах ответов также есть хорошо известная неоднозначность. В RFC специально для OCSP есть проблемы, заключающиеся в том, что хороший и неизвестный ответ одинаково действительны для сертификата, о котором проверка не знает.
Обсуждение альтернатив:
Существует два основных метода проверки сертификатов: белый и черный список.
Протоколы «черного списка» включают CRL, OCSP и SCVP, а затем варианты OCSP.
Белый список в Windows может быть выполнен с использованием интерфейса OCSP с CA DB, CTL * и SCVP.
В большинстве случаев методы белого списка считаются более совершенными, более безопасными, быстрыми, более оперативными и лучшими альтернативами методам черного списка.
Один из способов получить дополнительную информацию об этом - включить журнал событий CAPI2.
Информация, которая отображается в журнале событий, поможет определить, где процесс проверки сертификата занимает длительный период времени.
Чтобы включить ведение журнала
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
Чтобы сохранить журнал в файл
wevtutil.exe epl Microsoft-Windows-CAPI2/Operational filename.elf
Чтобы отключить ведение журнала
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false
Чтобы очистить журналы
wevtutil.exe cl Microsoft-Windows-CAPI2/Operational
Как бы то ни было, существует исправление, которое может не решать конкретную проблему, но содержит обновленный файл cryptnet.dll для устранения проблем с OCSP. Этот конкретный файл также не обновлялся в SP1.
Вы не можете использовать метод входа на основе сертификата для проверки подлинности запросов на компьютере под управлением Windows Server 2008 R2