Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

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

6 Answers 6

up vote 1 down vote accepted

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

share|improve this answer

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

share|improve this answer
    
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 '09 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. –  Evan Anderson Aug 11 '09 at 19:27

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!

share|improve this answer

Setting

authentication level:i:0

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

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.