Certificate Revocation List (CRL) - Client's Cache

I am working right now on developing .Net SmartCard Application Block as I couldn’t find any working framework  dealing with SmartCards and .net which would give me the ability to validate pin cards, encrypt data, sign data and more.

One of the things needed to be handle when implementing PKI in an organization is a way to revoke certifications, this is where the Certificate Revocation List may come handy BUT what you find out if you’ll try to implement PKI is that you publish a new revocation list the and the client does not give a damn ! … It made me crazy for a day….

I revoked a certificate but when I checked if the certification is valid I got the annoying ‘true’ meaning it is still valid…. My guess was that the CRL list is being cached on the client side which is normally a good idea… but not for testing and the minimum caching time could be set to 1 hour and couldn’t have the pleasure to wait 1 hour between testings.

So… I started the quest for the cache…I searched and searched and did some more searching on where the list was hidden and here are my findings:

There is no simple way to force the cached CRL to refresh. The CRL has an Expiry Date after which it will be renewed. A whitepaper about certificates and caching can be found at here

According to this paper the CRL can be cached in various locations:

- Memory
- Local File System.

In order to clear the CRL cache immidietly do the following:

1. Memory – You need to restart the application which is checking the CRL validity as it seems that in my case when using CAPICOM isValid the state is not refreshed immidiatly until the process restarts.
note: if you are trying to debug inside Visual Studio you will have to close and open the Studio of just start the process outside the studio for the memory to get refreshed.

2. Local File System – the cache file is stored in the following directories:
\Document and Settings\Username\Application Data\Microsoft\CryptnetUrlCache\Methadata 
Delete the file in this directory.

( if this procedure haven’t worked for you for some reason I've found out that there is a similar directory under
%windir%\system32\config\systemprofile\Application Data\Microsoft\CryptnetUrlCache but i didn’t have to touch it)

I hope this information will help someone and save some massive amount of time that can be waist trying to figure out what the hell is going on with the client’s cache.

 

6 Comments

  • Hi, i tried and couldn't find the "CryptnetUrlCache" folder under "\Document and Settings\Username\Application Data\Microsoft" directory, and removing "%windir%\system32\config\systemprofile\Application Data\Microsoft\CryptnetUrlCache" doesn't help. is there anywhere that the hash might be cached?

  • Hi Serge,



    What operation system are you using ?

    Just a simple check... you did replace the username... with your username right ?



    Ohad.

  • i am using Windows XP Pro. yes i did replace the username with "user1", which is the actual username that i am using but is doesn't work.

    These are what i did:

    This particular user was logout and therefore i log into the local machine as administrator and removed the cache as per what you mentioned. i uploaded a new CRL which doesn't have the serial number of user1 in the CRL list. user1 still is not able to login. I am using a 3rd party CA.

  • Thanks, it's help.

  • please tell one more thing, how can we set this cache to expire or to set this cache expiry time?

  • I installed certutil on my XP machine and tried that:

    certutil -urlcache -v (shows all entries in detail)
    certutil -urlcache * delete (deletes all entries)

    If you want to check your crl distribution points immediately (and download the new crl at the same time) try this:
    certutil -url mycertificate.cer
    With the URL retrieval tool you can check the CRL.

    Maybe it helps.


Comments have been disabled for this content.