3

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)

alt text

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:

alt text

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.

4
  • Where did you find the authentication level fix? If you got it from my website I want an upvote :)
    – tsilb
    Nov 4, 2009 at 2:14
  • What's your website? Perhaps I can remember :-)
    – tomfanning
    Nov 5, 2009 at 11:11
  • 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. :)
    – user156693
    Jan 30, 2013 at 3:04
  • No worries - more than welcome :-)
    – tomfanning
    Jan 30, 2013 at 11:59

6 Answers 6

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

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).

2
  • 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.
    – tomfanning
    Aug 11, 2009 at 13:48
  • 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. Aug 11, 2009 at 19:27
1

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!

0

Setting

authentication level:i:0

in the custom RDP settings works around this issue (as posted in my question)

0

Get a SAN certificate with multiple names and local hostnames or ip adresses. This will work perfectly.

0

If you want to fix this without reducing your auth level, open Remote App Manager and click change next to "RD Session Host Server Settings" Verify that the Connection settings Server name has the corerct external DNS. In the same dialog click the Digital Signature tab and set it to the correct SSL certificate.

Note that you also have to configure the external cert in the Session Host Configuration RDP-Tcp properties as JT posted.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .