Link to home
Start Free TrialLog in
Avatar of AndrewLauden
AndrewLaudenFlag for United States of America

asked on

SSL Setup for RemoteApp using TS Web Access Server

I have a TS Web Access Server running on the same machine as a TS Gateway.  This machine has an SSL cert and is functioning well.  I had some SSL issues with customers connecting to the RemoteApp server (ras.mydomain.local) so I got an SSL cert for the local FQDN and installed it on the RemoteApp server.  I thought all was well, but some clients get an error, "The certificate or associated chain is invalid."  I have checked the Certification Path using IIS on the RemoteApp server and it's properly configured.  After reading that not all SSL certs are created equally, I though i would try one from Thawte to replace the GoDaddy one I have.  While I was doing that, i stumbled across the notion that perhaps i should have a public FQDN for the RemoteApp server.  Is this the case?  Seems odd to me--b/c i want to protect the RemoteApp server by using TS Web Access / TS Gateway.
Avatar of oztrodamus
Flag of Australia image

With the cert from GoDaddy did you install the intermediate root certificates provided along with your SSL cert?
Avatar of AndrewLauden


Yes, I installed them on the RemoteApp server and the Gateway server.
Are you able to connect even though you are receiving the error? If that is the case than what I think is happening is the public FQDN used by the client to connect is different than the common name of the certificate.

I haven't done this, but I believe it will work. Configure a secondary NIC on the TS Gateway server and add a DNS suffix on the secondary NIC that matches the public FQDN. Remember to make sure the secondary NIC binds the new dns suffix first, or only the new DNS suffix. Then bind the SSL cert to the secondary NIC. The public FQDN will then match the common name of the cert, which should be

Another approach would be to use MS ISA2006 server, which would allow you to proxy your incoming connections. This is a much better approach and one I would recommend. You can then enforce AD permissions and require the user to provide a user name and password before the ISA server will allow them to connect to the terminal server. I know TS Gateway is supposed to allow you to directly connect to your terminal servers from the Internet, but just because you can doesn't mean you should.
Thanks.  The Thawte cert hasn't improved anything.  I'll try some more and consider the ISA server.  Does the App Server need to be publicly available?
The TS Gateway server should be the sever the clients are targeting from the Internet.
Yes, that is the case.  Clients browse to which requires a login.  From there, they launch RemoteApps hosted on anther machine.  The SSL issues arise when launching the apps listed in the TS Web Access site.  When theey connect to the RemoteApp server, they're connecting to another machine with a local domain name (not a public domain name).  I have an SSL cert for the local machine using its local domain name (ras.mydomain.local), and for most clients it works fine.  For some, there is an issue with the Certificate Path even though the intermediate certs are properly installed on the RemoteApp server.  Prior to installing an SSL cert on the RemoteApp sever, I had imported the cert from the TS Web Access site and used it to secure the TS connections.  I ran into the issue that the RemoteApp server's certificate didn't match it's domain name (ras.mydomain.local).  That seemed to fix the SSL issues until recently.

Does the TSGateway box have seperate interfaces for external and internal traffic?
It does have two NICs and external traffic comes in via one of them (routed by firewall).  Other than that, I have not done anything to separate traffic on them.
Is the external NIC on the TS Gateway box on a seperate network?
No, same physical network with DHCP running on 2008 domain controller.  (NICs have IP reservations)
Yes, but are they on the same subnet?

Just an FYI server's should always use static IP's.
Thanks, yes, same subnet.
I believe that is where the problem is coming from. You need to put the external NIC on a seperate network. It doesn't matter that physically they use the same switch. What matters is the NIC's are not on the same subnet. This will ensure proper traffic flow.
Thank you.  I am out of the office at the moment and will implement your solution when I return.  I will report back in a week.
I found that the Gateway's default website was bound to the the port that was not receiving external traffic--so I fixed that and put the proper NIC on a separate subnet.  The problem with the certificate chain on ras.mydomain.local remained.  I then removed the purchase certificate (used Auto Generated one instead) from the RDP-TCP connection on the Remote App server and the issue is gone!   My understanding was that the only cert required was on the Gateway--could the NICs on the Gateway being on the same subnet have caused an issue that lead me to install a cert on the Application Server to begin with?  Is there any scenario where the Application Server would need a cert?
Now when users attempt to log in, they get a warning that the RemoteApp is from an Unknown Publisher and after that an error kicks up that the Cert on the remote computer is not from a trusted certifying authority.  If I view the certificate, it shows that it is the the default one generated certificate. ( So now, I'm back at square one.
I've modified the Terminal Server settings from the TS Remote App Manager on the RemoteApp server: 1) unchecked the "Require server authentication" 2) removed ".domain.local" from the Server name, and on the  Digital Signature tab, I selected the Gateway Server's certificate.  All seems to be working now.  

What is the downside of unchecking the "Require server authentication" option?
I now have several users, some using client v7 and some v6 that are getting repeat login screens upon clicking on the RemoteApp icon on the TS Web page.  For other users, two or three attempts results in a successful launch of the RemoteApp, while others never get through.

Avatar of AndrewLauden
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The remaining issue is a know Microsoft bug.  All of the recommendations made by participating experts have been helpful and wise but did not solve the problem.