How to Disable CRL Checking
I went down the rabbit hole of certificate-revocation lists today, and came up with a headache. Yet more time wasted wrestling with security infrastructure. Such a shame that people aren't better behaved -- so much human effort is wasted on security measures.
What started it all was a problem where our .Net application was taking a very long time to start up (on the order of several minutes), but only on machines without Internet access. The root of the problem, it turns out, lay in the delay that was occurring while a .Net security component awaited a response from http://crl.thawte.com. The security component was dutifully trying to get an updated list of revoked code-signing certificates, so it could be absolutely certain that the assemblies in question had not been tampered with.
And it turns out you can turn off CRL checking. This article nicely summarizes the problem and describes your options: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282 . You can turn CRL checking off on a machine, or on a specific .Net application.
Disable CRL Checking Machine-Wide
Control Panel -> Internet Options -> Advanced -> Under security, uncheck the Check for publisher's certificate revocation option
Disable CRL Checking For a Specific .Net Application
See this Microsoft KB Article: http://support.microsoft.com/kb/936707
The Right Answer
Disabling CRL checking is handy when you trust your assemblies or you trust that their code-signing certificates will not be revoked. But, from a security best-practices point of view, what you should really do is routinely download up-to-date CRLs and install them on the machines that don't have Internet access. How best is this accomplished? I don't know. If someone stumbles across this post and knows how to do this, via Active Directory for example, let me know!
What started it all was a problem where our .Net application was taking a very long time to start up (on the order of several minutes), but only on machines without Internet access. The root of the problem, it turns out, lay in the delay that was occurring while a .Net security component awaited a response from http://crl.thawte.com. The security component was dutifully trying to get an updated list of revoked code-signing certificates, so it could be absolutely certain that the assemblies in question had not been tampered with.
And it turns out you can turn off CRL checking. This article nicely summarizes the problem and describes your options: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282 . You can turn CRL checking off on a machine, or on a specific .Net application.
Disable CRL Checking Machine-Wide
Control Panel -> Internet Options -> Advanced -> Under security, uncheck the Check for publisher's certificate revocation option
Disable CRL Checking For a Specific .Net Application
See this Microsoft KB Article: http://support.microsoft.com/kb/936707
The Right Answer
Disabling CRL checking is handy when you trust your assemblies or you trust that their code-signing certificates will not be revoked. But, from a security best-practices point of view, what you should really do is routinely download up-to-date CRLs and install them on the machines that don't have Internet access. How best is this accomplished? I don't know. If someone stumbles across this post and knows how to do this, via Active Directory for example, let me know!
posted by Mark at 5:17 PM
0 comments
