Статус: Новичок
Группы: Участники
Зарегистрирован: 10.06.2008(UTC) Сообщений: 1
|
Кто-нибудь знает какие флаги нужно использовать в параметрах функции CertGetCertificateChain при проверке цепочки сертификатов, чтобы функция каждый раз обращалась по CDP сертификата.
Сейчас использую флаги CERT_CHAIN_REVOCATION_CHECK_END_CERT и CERT_CHAIN_REVOCATION_CHECK_CHAIN, при этом функция первый раз лезет в Интернет за списком отзыва, а второй и последующий разы берет видимо из каких-то локальных хранилищ, т.к. время значительно уменьшается. Очистка CryptnetUrlCache не помогает
Может кто-то знает где ещё система может хранить списки отзыва и как почистить эти хранилища, чтобы функция при каждом её вызове в первую очередь смотрела список отзыва из Интернета по CDP.
Буду благодарен за любые конструктивные замечания и ссылки в сторону решения проблемы.
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 29.12.2007(UTC) Сообщений: 22 Откуда: Екатеринбург
|
Sergey S. написал:Кто-нибудь знает какие флаги нужно использовать в параметрах функции CertGetCertificateChain при проверке цепочки сертификатов, чтобы функция каждый раз обращалась по CDP сертификата. Судя по всему, CryptoApi не предоставляет такой возможности: Цитата:CRL and AIA Caching
To increase performance, the CryptoAPI caches CRLs and certificates referenced in AIAs. The entries are cached in memory on a per process basis. The chain engine does not purge its memory cache until the object expires and there is no way to force the chain to flush its memory cache except to restart the host process.
Base and delta CRLs are cached in memory for each application that calls the certificate status checking APIs. This may require an application to be restarted before the application will determine that a locally cached CRL no longer exists and must be fetched from the CDP location in the certificate. The Windows operating system does not support manual or programmatic flushing of the CRL cache. CryptoAPI also does not support forcing the download of a CRL object when an existing valid CRL has been cached in memory or on the disk subsystem.
The benefit of caching CRLs locally is that CryptoAPI will always look for a cached copy first to avoid traversing the network, generating additional download traffic, and introducing latency in the revocation status checking.
The disadvantage of local caching is that the client will not look for a new base CRL or delta CRL until the CRL has expired. Therefore, if a revocation has occurred on a CA and a new CRL is published, the client may not download the updated CRL due to having a time valid locally cached copy.
Note Certificate caching is a core functionality of CryptoAPI. Its behavior cannot be modified or turned off.
During certificate status checking, valid certificates and CRLs cached in memory are always preferred before a certificate store search is performed. If a certificate or CRL is not in the cache or certificate store, CAPI will download them using information in the AIA or CDP extension of the certificate.
Certificates are cached when CryptoAPI retrieves them from a certificate store or a URL. The cache location varies depending on the source where a certificate or a CRL was retrieved. A certificate or a CRL can exist in one or several of the following locations.
* Memory All valid certificates and CRLs that have been touched by the chain-building engine since the last reboot are cached in memory.
* Certificate Store All certificates that are not treated as root CA certificates and that have been retrieved from an HTTP–, LDAP– or FILE–URL reference via the AIA certificate extension are cached in the certificate store if the certificates are found to be part of a valid chain by the CryptAPI. Root CA certificates are not automatically cached and must be added explicitly by the interactive user to the corresponding certificate store.
* Local File System When a certificate or CRL is retrieved via LDAP or HTTP by a Windows 2000 client with MS04-11, Windows XP SP2 client, or Windows Server 2003 client, it is cached by CAPI in the “Application Data” folder. The per-user cache location is “C:\Documents and Settings\{user name}\Application Data\Microsoft\CryptnetUrlCache” and the per-machine cache location is “%WINDIR%\System32\config\SystemProfile\Application Data\Microsoft\CryptnetUrlCache”.
Windows 2000 with MS04-11, Windows XP, and Windows Server 2003 handle caching for HTTP–, LDAP–, or FILE–URL references exclusively with CAPI. Earlier versions of CryptoAPI used WinInet instead of CAPI for this purpose. Остается либо самому реализовывать проверку цепочек сертификатов, что весьма трудоемко, либо посмотреть в сторону OCSP для реализации он-лайн проверки статуса сертификата. |
С уважением, Андрей Костоусов СКБ Контур |
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close