Share via


IIS, CRL checking, CertCheckMode=4 and RevocationFreshnessTime Metabase Property

While recently working on a related incident, I noticed that a lot of folks are getting issues with the usage of CertCheckMode=4 (MD_CERT_CHECK_REVOCATION_FRESHNESS_TIME) in IIS6. This feature is supposed to allow frequent CRL refresh per IIS documentation :

The client CRL is replaced by the CRL at a remote location, even if the CRL that is cached on the client is valid.
The value of the RevocationFreshnessTime Metabase Property determines the frequency of this action.

While the above statement is almost true, the documentation is missing an important note : the CRL publishing time must match the RevocationFreshnessTime configured. So, if you set a freshness time of 3600 seconds, the CRL must be published at least every 3600 seconds.If the CRL is not "fresh enough", it is considered as invalid and you'll immediately get the following error even for valid client certificates :

"HTTP Error 403.13 - Forbidden: Client certificate has been revoked on the Web server.

The following thread describes a similar issue when directly using CertGetCertificateChain API passing dwRevocationFreshnessTime value :

"If you set the freshness time to only 10m and the CRL that is downloaded from the server does not meet that freshness time, you'll get "revocation offline" errors. A freshness time of 10 minutes means the CRL must have issued in the past 10 minutes, which will rarely be the case.

 So, do you mean that setting the freshness time doesn't force a new CRL download and the only thing it does is communicating that the revocation server is offline? I don't understand the logic behind all this...

 correct. There is no way to force a CRL download using CryptoAPI or CAPICOM. The freshness parameter is used to evaluate the freshness of the information that is available."

A couple of observations regarding the IIS metabase entries :

Because of the constraints listed above, you cannot use CertCheckMode=4 to implement "real time CRL checking". You may consider other options like using delta CRLs, shorten CLR expiration or use OSCP. If client certificate mapping is used, a recommended approach consists to use account management and disable the relevant user account.

Emmanuel Boersma

Comments

  • Anonymous
    April 21, 2010
    The comment has been removed