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.