Q: How does Windows cache certificate revocation lists (CRLs)? How are the CRL caches used during certificate validation? Is a similar caching mechanism used for Online Certificate Status Protocol (OCSP)-based certificate validation?
A: Windows uses three different CRL cache locations: in system memory, on disk, and in the certificate store. The CRL cache in system memory is a per-process CRL cache, so every Windows process caches the CRLs it uses in its proper memory space. The CRL cache on disk is a per-user CRL cache. This means that processes running under the same user account will share the same user-level disk cache. The third cache location—the certificate store—is also user-specific. Contrary to the content of the process and disk caches, the certificate store cache content can be controlled by administrators using Group Policy Object (GPO) settings, which are in the Public Key Policies GPO container.
During certificate validation, Windows will first check the process's memory cache for a valid CRL. If it can't find a valid CRL in memory, it will check the user account's disk cache. Finally, if nothing is found in the disk cache, the user certificate store will be checked. If the required CRL is found in the certificate store, Windows will copy it to the user's disk cache and the process's memory cache. If none of the caching locations contain the required CRL, Windows will download the CRL, based on the content of the CRL Distribution Point (CDP) field in the certificate that's to be validated. After a successful CRL download, Windows will store the CRL in the user cache and memory cache, but not in the certificate store. If a CRL is downloaded through HTTP, it will also be put in the user's Internet Explorer (IE) disk cache—although this isn't the case if the CRL is downloaded, for example, from Active Directory (AD) using an LDAP-based CDP.
Real-time OCSP-based certificate validation uses a similar caching mechanism. The only difference is that the certificate store-based cache isn't used. OCSP responses are never cached in the certificate store. If they can't be found in the memory or disk cache, an OCSP request is sent to the OCSP responder (i.e., the OCSP server) that's specified in the certificate.
