We help IT Professionals succeed at work.

Remote Desktop Connection triggers "A revocation check could not be performed for the certificate" from systems not part of Active Directory Domain

bluemercury
bluemercury asked
on
At my firm, we have various remote workers who utilise a combination of L2TP/IPSec VPN and MS Remote Desktop Connection to connect directly to their workstation onsite. In the wake of the coronavirus implications, I am having to expand to our full (generally less technically minded) workforce very quickly, so want to get rid of a unhelpful error message on connecting.

Some quick facts:

1) I have a AD integrated Certificate Server, already correctly configured to issue certificates appropriate for use in the Remote Desktop setup
2) I have applied the appropriate settings through Group Policy to apply the Certificate Template, and also things like enforcing SSL, etc.
3) Connections are straight from the RDC client to the workstation, no brokers or anything like that.
4) Users connecting in from home are NOT part of the Active Directory Domain.

When a user tries to connect in, they get the following warning:

"A revocation check could not be performed for the certificate". If they ignore this, the connection is then successful.

On closer inspection of the Certificate being served up to the RDC, the CRL Distribution Point they are being served is based on LDAP. As they are not part of the AD Domain, my feeling is that this LDAP location is probably inaccessible due to a lack of valid authentication.

I'm aware I can change settings on the CA server properties, but I'm weary of doing this as I do not want to break our domain in any way. What would be ideal would be for someone to talk me through exactly what I can do to make an http based CRL Distribution point and set it as the priority served up to RDC clients when they try and connect from outside the domain, so they can check for Certificate Revocation without needing AD authentication.

Many thanks in advance :-)
Comment
Watch Question

View Solution Only

David Johnson, CDSimple Geek from the '70s
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
I use //pki.domain.com which is a publicly available website that CS publishes crl's and aia's to.
bluemercury

Author

Commented:
Hi David - thanks for that, but could you give a bit more detail for me to follow?

Many thanks
David Johnson, CDSimple Geek from the '70s
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
this is one of the things you should have thought about when createing the CA.  You are going to have to tear down and rebuild.  People here keep saying you don't need to crate a capolcy.inf but it is my experience that it greately simplifies things.
I also publish the public keys to the pki web server to facilitate s/mime.  There is no loosening of security doing this.
here is a walkthrough https://www.petenetlive.com/KB/Article/0000957
bluemercury

Author

Commented:
Hi David.

The CA was setup longer ago than I can remember - at a guess, as far back 2009. I can't even remember what its purpose was at the time. I think it was me that did it, but I can't be 100% sure even of this!

Thanks for your post back. The link above was one of the ones I'd already found through Google but it wasn't working for some reason. I carried on my search, and the page I found here was very useful and led to a solution. It required some adapting, but the key thing that helped everything work was the suggestion to flush all entries for CDPs and AIAs, so that there were no longer any LDAP based entries. Then I followed the guide and read between the lines on bits to get everything working without needing to involve LDAP.

I did also end up hosting the CDPs and AIAs on another server via IIS, that has been made public Internet http accessible via port 80 on our firewall. I suspect I could have got it to work on the existing CA's install of IIS, but somehow it felt a little more secure not directing public web traffic straight to our CA (which is also a DC) and instead to a server that is currently running IIS, file sharing and nothing else.

Thanks for your post i ntrying to help :-)
Commented:
Adapting the guide I found myself here presented a solution: https://www.vkernel.ro/blog/how-to-publish-the-crl-and-aia-on-a-separate-web-server

As instructed in this guide, emptying the list of CDPs and AIAs and recreating from scratch was the only way I could find to make this work - for anyone reading this, leaving the LDAP entries in still caused the certificate revocation check to fail, even when other viable methods were presented (this may be due to the impatient nature of the Remote Desktop Client, timing out before attempting an alternative method listed in the certificate). Removing all entries and creating my new custom ones has presented no negative effects, but it may be wise to make a copy of your existing entries (as I did before deleting anything) in case it does present a problem and you need to add them back!

As the title of the guide suggests it promotes the idea of having the CDPs on a different IIS web server, which I rolled with and I sense is probably more secure than trying to host on the CA directly, so worth the trouble of setting up another member server if you have the licenses (on I guess in theory you could do with an alternate web server on Linux, etc).