Certificate issue with RemoteApp on Server 2008

Question

I am trying to set up a proof-of-concept demo for deploying applications via RemoteApp, the application-streaming-over-RDP stuff in Windows Server 2008.

The TS Gateway server (call it srv-web) and the box hosting the applications (call it srv-app) are two different boxes.

The connections need to come through a TS Gateway server over HTTPS, as srv-app is on an internal LAN behind NAT.

Only srv-web is exposed to the internet, and only port 443 (HTTPS) is open.

If I ignore/accept the various warnings, the connection works perfectly well.

The object here is to get things working as smoothly as possible for our clients.

I have an SSL certificate installed on both srv-web and srv-app. srv-web is set up to use it for TS Gateway, and that works fine. The CN of the certificate matches the external public hostname.

The warning I am getting is as follows (I have doctored the real hostname out of the screenshot)

My question, I suppose, is how to I choose the SSL certificate srv-app uses to provide proof of its identity to connecting clients?

EDIT: I found where to set this - it's in Remote Desktop Session Host Configuration -> RDP-Tcp properties, general tab at the bottom.

However I have another problem, somewhat predictably I now have a mismatched server name:

I suspect this is going to require a topology change somewhere. Feedback from someone who's already done this would be great.

EDIT 2: I have worked around this by setting the following option in Custom RDP Settings.

authentication level:i:0

However this isn't a satisfactory solution as it is just disabling the check. I would still appreciate any more feedback on this.

Many thanks.

Solution 1

go to your rdp-tcp properties and choose the general tab-->and select your external cert at the bottom of the properties sheet. This will allow all communication to be based on the external cert instead of a mismatch when rdp uses the default internal for the server itself

Solution 2

It looks, to me, like you're trying to connect to the server using its "internal name" but you've selected the certificate that has an "external name" specified.

If you want the "internal name" to work "behind the firewall" and your NAT firewall doesn't support "hairpin NAT" (i.e. NAT'ting a request coming from the LAN interface back to the LAN interface) then you could do the classic "cheat" of creating a DNS zone in your internal DNS servers named "publicname.ourdomain.com" with a single "@" A record in it that contains the internal IP address of the server computer.

It's like "split horizon DNS", but constrained to a single name (so that "normal" name resolution of the rest of the "ourdomain.com" zone is unaffected).

Solution 3

I've seen this in our own environment. From what I can see, a Gateway-tunneled RDP connection will actually use two sets of certificates: First it will encrypt the tunnel between the client and the gateway, and then secondly between the client and the server (although this traffic already is inside the gateway-secured tunnel). It baffled me as well, and I haven't found any other "proper" way to do it than to use two certificates, one that matches your gateway's external name, and one that matches the internal name of you TS Server. Please update this thread if you find anything!

Comments

[tsilb]

Where did you find the authentication level fix? If you got it from my website I want an upvote :)

[Olof Åkesson]

What's your website? Perhaps I can remember :-)

[Admin]

THANK YOU so much for posting this question (and following up with the answer)! This was really hassling me and I couldn't find a good solution. My server cert was internally signed, whereas my external address/cert is signed by a trusted CA. I couldn't have the two matching, and since I was off-network it was really puzzling me until I found your article. So thanks again, even after all these years. :)

[Olof Åkesson]

No worries - more than welcome :-)

[Olof Åkesson]

Hmm, I'm not so sure this is the problem. Remember that a TS Gateway server is in use, and that allows you to connect to a machine by its "internal name" (e.g. srv-app.ourdomain.local) even when outside the LAN. DNS and routing wise, everything here is fine. I have to have the certificate with the "external name" selected because the certificate with the "internal name" isn't issued by a trusted root CA. I am about to update my question with a workaround I've just found, anyway.

[Spence]

If your clients are using the "internal name" but the certificate has the "external name" specified then you're going to get an error. Likewise, if you use the certificate with the "internal name" but the certificate is untrusted to the clients you're also going to get an error.