[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1628
  • Last Modified:

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 wa.mysite.com 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.
0
AndrewLauden
Asked:
AndrewLauden
  • 13
  • 7
1 Solution
 
oztrodamusCommented:
With the cert from GoDaddy did you install the intermediate root certificates provided along with your SSL cert?

http://help.godaddy.com/article/869
0
 
AndrewLaudenAuthor Commented:
Yes, I installed them on the RemoteApp server and the Gateway server.
0
 
oztrodamusCommented:
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 hostname.domain.com.(x)

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.
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
AndrewLaudenAuthor Commented:
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?
0
 
oztrodamusCommented:
The TS Gateway server should be the sever the clients are targeting from the Internet.
0
 
AndrewLaudenAuthor Commented:
Yes, that is the case.  Clients browse to wa.mysite.com/ts 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.

0
 
oztrodamusCommented:
Does the TSGateway box have seperate interfaces for external and internal traffic?
0
 
AndrewLaudenAuthor Commented:
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.
0
 
oztrodamusCommented:
Is the external NIC on the TS Gateway box on a seperate network?
0
 
AndrewLaudenAuthor Commented:
No, same physical network with DHCP running on 2008 domain controller.  (NICs have IP reservations)
0
 
oztrodamusCommented:
Yes, but are they on the same subnet?

Just an FYI server's should always use static IP's.
0
 
AndrewLaudenAuthor Commented:
Thanks, yes, same subnet.
0
 
oztrodamusCommented:
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.
0
 
AndrewLaudenAuthor Commented:
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.
0
 
AndrewLaudenAuthor Commented:
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?
0
 
AndrewLaudenAuthor Commented:
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.
0
 
AndrewLaudenAuthor Commented:
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?
0
 
AndrewLaudenAuthor Commented:
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.

0
 
AndrewLaudenAuthor Commented:
This is a known issue: http://support.microsoft.com/kb/969084 
0
 
AndrewLaudenAuthor Commented:
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.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 13
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now