Revocation checking fails when CDP/AIA locations in the CA's cert can't be reached

Error:

 

A Certificate request fails with: "The certification authority denied the request. The revocation function was
unable to check the revocation because the revocation server was offline."

 

OR:

 

Certificate services just fails to start with similar errors as in KB 825061. It’s a similar revocation error deep down, though.

 

Workaround:

 

To temporarily work around the issue in Windows 2000, use the method described in KB 825061. To work around it in 2003, set the CRLFLags value to basically tell it to ignore revocation errors:

 

   certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

 

Restart certificate services in both cases, and it should now start and/or also issue certs once more. But this is a temporary fix if you’re dealing with a subordinate CA (read below).

 

What does the error mean? How do we fix it?

This error is usually going to indicate that the CDP locations listed in the CA’s certificate can’t be reached. How to verify this:

 

  Certutil –verify –urlfetch <CA cert>.cer

  Certutil –url <ca cert>.cer

 

This is going to show the same revocation error perhaps for one or more CRL locations. We need to then determine if the CRL location (https://, ldap:///, file://) is actually pointing to a bad server (that doesn’t exist and will never exist) or to a valid server… that just doesn’t have the CRL properly installed/copied. If the CRL is just not there, copy it to that location (http/file) or use certutil –dspublish to import it to the AD.

 

If the CRL location is permanently bad…

 

- Is this a root CA?

o In theory, the Root CA’s cert should have empty CDP and AIA paths (good design), as it would never need to check those CDP/AIA paths for any revocation functions. To keep things simple, you should be able to run the certutil command to just disable offline revocation failures.

- Is this a subordinate CA?

o If so, you would need to renew the CA’s cert, this time with good CDP/AIA locations. Where does the subordinate cert get its CDP/AIA locations from? From the extension settings of the root CA (not the CAPolicy.inf J). Go to the root CA certification authority snapin, right click on the name of the CA, go to properties, to the Extensions tab, and set up proper CDP and AIA paths that the subordinate CA(s) can access. Then, re-request the subordinate CA’s cert with the SAME key pair, install it (certutil –installcert), and you should be good to go.