·When a Client certificate is presented to an IIS website, IIS looks for the CRL verification to determine the validity of the certificate, much in a similar way a browser does the CRL checking for an SSL enabled website. When IIS receives the client cert it looks into the CDP (CRL Distribution point) under the details tab of the client cert. It then uses one of the HTTP/LDAP links listed there to download the CRL on the server. This link will basically be pointing to one of the CDP servers hosted by the CA. IIS uses this link to download the CRL for future verification purpose. This is overall what IIS does. Obviously internally it is making calls to Crypto Subsystem for all these activities.
When does IIS kick off a new download of a CRL? Does it look at the Next Update field within the CRL and then keep a log (somewhere on IIS or registry) on when it requires to download the next CRL from the CA?
To answer the above question in specific it depends upon various settings/scenarios as described below.
IIS by default looks into the downloaded CRL for the next update field. This is stored in its own memory cache and also physically in the server under either
%windir%\System32\config\systemprofile\Application Data\Microsoft\CryptnetUrlCache\MetaData (on Win2k3 server), or
%windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData (on Win2k8)
You can find the cached CRLs using this command as well Certutil –urlcache CRL at a command-line prompt.
If the current date is well behind the ‘Next Update’ field value it will use the current CRL to validate the client certificates.
CRL verification depends upon the metabase properties (IIS 6.0) like CertCheckMode, RevocationFreshnessTime and RevocationURLRetrievalTimeout.
1. If CertCheckMode is set to 0, IIS does the CRL verification based on the cached CRL on the server (based on its properties like current date and ‘Next Update’ field).
If the current date is in the range of ‘Effective Date’ and ‘Next Update’ fields it will use the local CRL cache. If the current date is beyond ‘Next Update’ field it will try downloading the CRL from the remote location and use it.
2. If CertCheckMode is set to 1 Certificate revocation checking is not performed.
3. If CertCheckMode is set to 2 Certificate revocation verification will be done based on the cached CRL on the IIS server. IIS will not try to connect to the remote server to download the CRL even if it has expired and in which case CRL verification will obviously fail.
4. If CertCheckMode is set to 4 Certificate revocation verification will be done by downloading the remote CRL, even if we have the valid cached CRL on the server. It ignores the cached CRL completely.
The frequency with which we download the remote CRL depends upon the value of the metabase property called RevocationFreshnessTime.
If this property is set to 1 (true) then the CRL on the server is updated from the remote location (even though local cached CRL is valid) every 1 day by default. If the metabase property RevocationFreshnessTime is set to a higher value (instead of 1) IIS uses its value directly to look for the frequency with which CRL is updated. Remember the value defines the time interval in seconds.
This default timeout interval for updating the CRL is controlled by another metabase property called RevocationURLRetrievalTimeout. This defines the timeout interval in milliseconds. You can increase this value if you think there might be some latency in downloading the CRL from the remote server.
When you are dealing with the 4th option above ensure you check this link in case you are getting this same issue.
Hopefully the above explanation gives you an idea as to how and when IIS asks the Crypto subsystem to retrieve a copy of the CRL. This is finally done by Schannel during TLS negotiation.
In IIS 7+ you can use netsh commands to set different values for CRL verification (Equivalent to setting CertCheckMode in IIS 6.0). Refer to this and this for details.