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 (1)

  1. Craig Humphrey says:

    Hi Emmanuel,

    interesting article.  I’m seeing something similar, only I think it’s in the reverse.

    I have Win2003SP2R2 CA that publishes a CRL, which is then served up by IIS on the same box.

    But when I attempt to download the CRL (e.g. in a browser) using:


    I only ever get the originally published CRL, never a refreshed one.

    OK, so there are no certs in the CRL, but it seems to have gotten stuck.

    I’ve tried manually republishing the CRL, setting expire headers in IIS and using IISRESET but it still gets the old one.

    If I load the CRL off the filesystem, I get the right one.

    Any ideas?

    I know this isn’t exactly the same as the Freshness issue you’ve discribed, but could it be related?

    Note: this has come about because I have a third party application that is trying to check the CRL and it was complaining about it.