Delete local CRL cache in Windows


Windows automatically caches retrieved CRLs and OCSP reponses. The advantage is that it speeds up revocation checking and uses less network bandwidth. The disadvantage is that clients will not detect new CRLs until the local cache expires.

Normally you should adjust the regular CRL publication intervals on the Certificate Authority so that you do not need to manually trigger the downloading of new CRLs before the locally cached versions expires. But in some testcases you might need to. So how do you accomplish this?

Note that this only works in Vista and newer!

The short answer

Run the following command in an elevated prompt:

certutil -setreg chain\ChainCacheResyncFiletime @now

Note that simply deleting the diskcache is not enough.

The long answer

When a process needs to find a specific CRL (to verify that a certificate is not revoked) it looks for a timevalid CRL in the following order:

1. The process’s own memory
2. The local disk cache
3. The local Certificate Store
4. The network location specified in the CDP of the certificate (HTTP/LDAP)

If a process finds a valid CRL sonewhere in this process it stops looking and stores a copy of that CRL in it’s memory. When the process ends it flushes the memorycached CRLs to disk so that other processes can use it. There is no way to force the chain to flush the memory cache without restarting the process.

Cached CRLs that are located on the disk are maintained automatically. Before they expire Windows will automatically prefetch the next CRL. If that prefetched CRL is not used by any process it will be deleted from the cache. This prevents the disk filling up with unused CRLs.

The local disk caches are located at these locations:

Users disk cache:

Computers disk cache:

You can delete the cached CRLs on the disk by running the following command:

certutil -urlcache * delete
Note. This deletes both cached CRLs and cached OCSP responses. Change the * to either CRL or OCSP to selectivly delete.

However this will not delete any cached CRLs in the memory of different processes. It might also have problems deleting files that are locked by another processes. In one testcase 11 out of 121 CRLs were still there after trying to delete all.

So instead of only deleting some of the cached CRL you can instead invalidate all cached CRLs. You do this by manually setting an expiry date on all CRLs regardless of the validity time specified on the actual CRLs.

So by running the following command in an elevated prompt:
certutil -setreg chain\ChainCacheResyncFiletime @now
all locally cached entries are invalidated immediately.

To temporarily disable the cache for one day and two hours, run the following command:
certutil –setreg chain\ChainCacheResyncFiletime @now+1:2
This means that no cached CRLs will be used until after the specified time.

To delete the setting, run this command:
certutil –delreg chain\ChainCacheResyncFiletime
If the setting never has been manually set you will get an error, since the value will not exist. This is exptected.

To view the current setting, run this command:
certutil –getreg chain\ChainCacheResyncFiletime

I base this article on information found on several articles, blogs and other sources, both Microsoft and third party. If there are any errors in my interpretation of it all, please contact me so that I can update this article!

About Tom Aafloen

IT Security Advisor @ Onevinn
This entry was posted in Okategoriserade and tagged , , , , . Bookmark the permalink.

6 Responses to Delete local CRL cache in Windows

  1. Brian Komar says:

    Great article , Tom. The only thing I would like to stress is that you need to define your CRL revocation intervals so that you rarely have to take this measure. You do not want to base your revocation strategy on manually deleting the CRL cache. Still, it is a great thing to have in your back pocket when an emergency revocation must be recognized.
    One clarification too… You must be running Windows Vista or Windows 8 or higher to use this command. This command does not work in Windows XP.

  2. Tom Aafloen says:

    Thanks for the feedback, Brian! I’ve updated the article with your suggestions.
    The purpose of my new blog is to collect thing to have in my back pocket, as you put it, hopefully others will find it useful as well.
    Have a great birthday!

  3. Tom,

    How relevant is this with Win10 1809 etc?


  4. Pingback: Where does Microsoft's Remote Desktop Connection (mstsc.exe) cache OCSP-responses? - Code Utility - Code Utility

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s