Possible causes of CRL validation error

Question

What are the possible causes of CRL validation error?

I run a network with my self-signed CA. But since three weeks ago, all of my RDP clients started saying that they had failed to validate the CRL. I thought that the webserver that hosts CRL was dead, but in fact it wasn't. I could access the CRL with no problem. I did absolutely nothing with the CRL when the error first started.

Google gave me little clue, most of the solutions were just turning the CRL validation off. But I want to really fix it, not just ignoring it. I tried regenerating the CRL file but it did not work.

openssl -gencrl -out crl/crl.pem

The above is the command I used to generate the CRL, straightforward. That is the very same command that I also used when I generated the first CRL. But the CRL generated this time is not working.

What else should I be looking for?

Solution

That's the thing with SSL certificates. You don't have to do anything for them to stop working. They expire on their own. You have to renew CRLs too. For Remote Desktop, you really should be using a Windows Enterprise CA in an Active Directory domain, and not OpenSSL. It will automate most of this stuff for you. I don't have enough detail to work out what else is wrong with your setup as it is though.

To answer your question, "what causes CRL validation errors?"

Just two things, really. Either the client cannot access the CRL Distribution Point (CDP,) or the CRL has expired.

Use this command to verify the correctness/validity of a certificate, including the CDPs:

certutil -f –urlfetch -verify mycertificatefile.cer

Are you using only HTTP CDPs, or do you also have LDAP CDPs. If you have LDAP CDPs, are you remembering to publish updated CRLs in Active Directory? Are your clients who are trying to validate the LDAP CDPs members of the same Active Directory domain so that they have permissions to read the CRL from LDAP?

http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx

Comments

[manatails]

Ok I solved it, it was my fault actually. the crl was being placed in non-chrooted environment so the web server couln't read it and was giving the old, expired one.