I logged into my home lab for the first time in a while and found that my MDM environment was no longer functional. After making sure the my MDM server was available externally, DNS records were all correct, and all MDM services were running, I checked the CA services. Yup, those were down. Not only that, but they weren’t starting up at all. I got the error above: “Unable to check revocation because the revocation server was offline.”
Didn’t I make all my CRLs public last time? I checked and yup, my intermediary CRLs were all available, and externally reachable. Uh oh. Do I need my root CRLs available too for this to work? It makes sense that the root CRLs have to be evaluated too, not just the intermediary.
I found this great blog post here at stealthpuppy and turned off the CA revocation check. That immediately solved my problem temporarily. But it didn’t solve my inherent problem: my CRL revocation checks were failing. It looks like the writer of stealthpuppy had the exact same problem I had, which was that the root CRLs were not updated and available.
Once I changed the root CRL expiration length and exported an updated CRL, all errors went away!
Notes:
- “certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE” is the command used to disable CRL check and make the error message temporarily go away.
- “certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE” is the command used to re-enable CRL check.
- Make sure the CRL of every CA in the chain is made publicly available and updated.
- If needed, make the expiration of a CRL very long so you don’t have to bring up the root CA often.
- I had an NDES error after all of this as well. HTTP 500 error when trying to load mscep_admin. I solved that by re-installing NDES and then a reboot.