Remote Desktop Connection triggers "A revocation check could not be performed for the certificate" from systems not part of Active Directory Domain
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 :-)
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 :-)
David Johnson, CD
I use pki.domain.com which is a publicly available website that CS publishes crl's and aia's to.
ASKER
Hi David - thanks for that, but could you give a bit more detail for me to follow?
Many thanks
Many thanks
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
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
ASKER
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 :-)
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 :-)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.