While setting up a PKI environment in our lab (using LDAP as our first CRL and HTTP as our second CRL), we noticed some weird behavior. We are using HTTP as a second CRL since most (if not all) of our clients are not joined to our lab environment’s domain.
When everything was installed and the certificates where distributed we noticed a weird error when connecting with RDP to one of our domain controllers. The error was “A revocation check could not be performed for the certificate”. Ok, this error would indicate that the client is not able to contact the CRL list which is located in AD and on the HTTP server.
While testing we noticed that the HTTP server was accessible for anonymous traffic. So that wouldn’t be the problem. While searching the internet for some relevant information we found two links which seemed to be related with our case. The Microsoft TechNet threads “Revocation check using LDAP URL fails” and “Certificate revocation check from external network”. While doing some tests we also noticed that domain joined systems didn’t have any of the same issues. So for some reason the RDP client could not failover to the HTTP CRL URL. To me it looks like a bug, and it’s something I’m certainly going to test more in a “private” lab within VMware Lab manager. Hopefully a sniffer trace or something like that will shed some light on this.
In the end we decided to change our PKI environment because we are lacking the time to trace the problem deeply. Instead of using Active Directory (or LDAP) as the first CRL and HTTP as the second CRL we switched it around and are now using HTTP as the first CRL and LDAP as the second CRL. This is currently working just fine.