I've recently setup a new domain joined Standalone CA on a Windows 2012 R2 server which is publicly accessible and authenticating fine, however, revoked certificates still appear to be authenticating. The actual server-side revoke process works fine as in the revoked certificate gets added to the CRL after publishing but the certificate still authenticates the client end.

I've added externally accessible CDP and AIA locations and have cleared the local CRL cache the client end using the following commands:

certutil -urlcache CRL delete


certutil -setreg chain\ChainCacheResyncFiletime @now

I'm aware of the minimum OS requirements for the last command. Clients are Windows 7 upwards.

I'm using a simple test app on the client that is configured to use the one certificate so if revoked would simply stop working but isn't the case in this instance. If I remove the certificate from local certificate stores then it does stop working so confident that it's dependant on this one certificate.

All web searches so far have led to the above commands and making sure the CDP is externally resolvable but I've covered those issues already.

I appreciate and advice

  • when I try to run certutil -setreg chain\ChainCacheResyncFiletime @now, windows indicates that i'm missing an argument, as if I have to add time on to @now. I've done this, but it still doesn't invalidate the cache. Commented Mar 8, 2019 at 15:07

2 Answers 2


Thought it was worth reporting my findings.

Turns out that Windows was revoking the certificates but there was some local caching of the CRL taking place as is intended by design. It seems that even when the certificate is showing as revoked, a cached copy is still used regardless until a specific period has passed, however, from my understanding the two commands I ran in my initial post should have expired this and requested an up-to-date one from the server but doesn't appear to be the case.

I've introduced delta CRLs which have made troubleshooting must quicker and all seems fine now so false alarm ultimately.

Thanks for your advice Greg


I'm using a simple test app on the client that is configured to use the one certificate so if revoked would simply stop working.

You need to verify the client is checking the CRL with a packet capture to your CRL on tcp/80. That would take five minutes.

If you want to validate that Windows CRL checking is working, you can use the following command on the client:

certutil -f –urlfetch -verify ExportedCertificate.cer

You also need to enable the CAPI2 event log, any CRL check failures will be logged there.

But the way an application uses and validates a certificate is not necessarily the same as how Windows would use and validate a certificate.

  • Thanks Greg. Once I'm back in the office I'll check this out and let you know my findings
    – jshizzle
    Commented Apr 22, 2017 at 16:16
  • In regards to your last paragraph, this is true and would be easier to tell if that was case if the certificate got marked that it's been revoked or now invalid, which I gather it does once updated CRL is used? The fact that it isn't leads me to address that it's simply a case of the certificate still thinking it's valid.
    – jshizzle
    Commented Apr 22, 2017 at 16:27
  • Ok, so ran the validate to see if Windows CRL checking is working and got the following result: >Load(CRL) returned The system cannot find the file specified. x80070002 (WIN32: 2) CertUtil: The system cannot find the file specified.
    – jshizzle
    Commented Apr 24, 2017 at 14:42
  • Errors seen were due to not running this on an exported crt file. The above command threw me by providing a .cer extension. Anyway, looks like this may be down to a bug in the app as have verified that the certificate is revoked with certutil yet the application still works so investigating this aspect. Thanks for the help.
    – jshizzle
    Commented Apr 27, 2017 at 8:16
  • I realize that my last update is rubbish as there's nothing wrong with the above command as an exported DER encoded certificate is in .cer format not crt. Apologies for the causing confusion.
    – jshizzle
    Commented Apr 27, 2017 at 9:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .