As students in my PKI training classes know, one of the areas I am a vocal about is the blind use of the CRLF_REVCHECK_IGNORE_OFFLINE setting in a PKI environment. I am so adamantly against the use of this setting, I personally refuse to ever explicitly share or type the syntax to enable this nasty beast. Unfortunately this setting pops up in vendor documentation, software deployment guides and other “authoritative” sources that place customers at risk. It is a classic example of where companies have written software or guides based on what they did in their test environments and unknowingly expose their customers to a big risk.
First, let’s talk about what this setting is all about. In practice, RFC 5280 defines the use of revocation information to indicate which certificates have been marked as untrusted and should fail validation checks by systems checking certificates from that issuer. If revocation details can not be retrieved or verified, a certificate should be assumed invalid. This means the inability to find and use a valid revocation source will result in errors to the relying party (unless we are talking about apps like Internet Explorer).
So what happens to environments to cause them to use this CRLF_REVCHECK_IGNORE_OFFLINE settings? Often when something has broken in their environment – such as failure to renew the CRL of an offline CA or access issues to a Certificate Distribution Point (CDP). Environments wind up seeing an error message like:
The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
So they search the Internet and find lovely nuggets of HORRIBLE advice that indicate “they too” had this problem and all they had to do to fix it was “run this command”. They then go on to show how to run the command to turn off revocation checking. If the CA is offline and the CRL wasn’t published properly or is expired, the fix is to republish the CRL. If the CDP location is inaccessible – fix the site! Don’t put a bandaid on a brain hemerage, fix the root cause.
The other place this issue comes up is software documentation and deployment guides – even from the largest companies. I have a plethora of documents and sites in my “to-do list” to contact and let them know the mistakes they are making in their documentation.
Take this one from VMWare and their documentation for VMWare Horizon 7 clients. If you look at step 12 you will see this doozy of a recommendation:
12. Enter the following command to ignore offline CRL (certificate revocation list) errors on the CA:
Say what? WHY would you ever recommend that to your customers?
My recommendation is to ALWAYS question any deployment, configuration or recommendation that has you running the command to turn off revocation checking. It’s there for a reason – to protect you. Fight back, rise up and refuse to accept that it “must just have to be that way since XXXX is recommending it”.