This is the third and final part of our recent series on configuring certificates on TS Gateway. See also Part I and Part II
TS clients authenticate TS Gateway server using server security certificates (X.509 format). TS Gateway passes the server security certificate to the clients during the SSL handshake process. During the SSL handshake process, the clients might drop connections because the certificate authority is untrusted or the TS Gateway server was unable to produce a valid certificate. In either case, the user will be unable to launch a remote connection using the TS Gateway. The following illustration summarizes certificate-related issues that can occur during connection establishment:
This blog identifies certificate-related connection issues that affect the user’s ability to establish a remote TS connection using the TS Gateway server, and actions that can be taken by end users and administrators to resolve these issues. For information on why TS Gateway needs a certificate and which is the recommended certificate to use on TS Gateway, see Part I: Introduction to TS Gateway Certificates . And for information on how to deploy a certificate on TS Gateway, see Part II: How to deploy a certificate on TS Gateway.
Certificate authority not trusted
Error message - “This computer can’t connect to the remote computer because the certificate authority that generated the Terminal Services Gateway server’s certificate is not valid. Contact your network administrator for assistance. “
Brief description - The TS Gateway certificate authority is not trusted by the client. This issue can most likely arise if the administrator has provisioned the TS Gateway with a self-signed certificate or private certificate authority.
Resolution (user-specific) - Import the TS Gateway certificate to the client machine and install it in the user trusted store.
To install the certificate in the user trusted store:
1. Download the TS Gateway certificate on the client machine.
2. Click Start, click Run, type “mmc.exe” (without the quotation marks), and then click OK.
3. Click File, and then click Add/Remove Snap-In,
4. Click the Certificates snap-in, and then click Add.
5. Click User account, and then click Next.
6. Click Local computer, and then click Finish.
7. Expand Certificates (Local Computer).
8. Right-click Trusted Root Certification Authorities, click All Tasks, and then click Import.
9. Use the Certificate Import Wizard to import the certificate to the user trusted store.
After completing the above actions, try reconnecting using TS Gateway.
Certificate identity mismatch
Error message – “This computer can’t connect to the remote computer because the Terminal Services Gateway server address requested and the certificate subject name do not match. Contact your network administrator for assistance.”
Brief description - The security certificate name presented by the TS Gateway server does not match the TS Gateway name. This can happen either because you used the TS Gateway NetBIOS name to connect or the administrator has incorrectly configured the TS Gateway certificate name with an internal FQDN name. You can verify the discrepancy by reviewing the server certificates as shown here:
For SAN certificates:
1) User action - Try reconnecting using the full FQDN of the TS Gateway server
2) Administrators action - If you are an administrator, verify that the TS Gateway certificate name matches the external FQDN of the TS Gateway server
Invalid TS Gateway certificate -
Error message – “This computer can’t connect to the remote computer because the Terminal Services Gateway server’s certificate is expired or revoked. Contact your network administrator for assistance.”
Brief description – The TS Gateway server certificate’s validity period has expired. For instance, self-signed certificates have a validity period of 6 months. You will see the following screenshot on the TS Gateway server manager snap-in (Administrator only):
Resolution (administrator action) - Create and assign a TS Gateway certificate. Refer to the –“Obtain a certificate for the TS Gateway server” section at the following URL:
No TS Gateway certificates received
Error message – “This computer can’t connect to the remote computer because no certificate was configured to use at the Terminal Services Gateway server. Contact your network administrator for assistance.”
Brief Description – The TS Gateway server certificate was either overwritten or was never configured on the TS Gateway. You will see the following screenshot on the TS Gateway manager snap-in:
The following screenshot represents the scenario in which no TS Gateway certificate exists for selection (Administrator action):
The following screenshot represents the scenario in which a valid TS Gateway certificate exists for selection (Administrator only):
Resolution (administrator action) – Create a certificate and export it to the certificate Personal store of Local Computer. Install the certificate on the TS Gateway. Refer to the –“To map a certificate to the local TS Gateway server” section at the following URL:
Note: If you continue facing issues while trying to bind the TS Gateway certificate – refer to the following KB:
Using TS Web, with Gateway. I've SSL enabled my TS Web site in IIS. Upon connecting and launching a remote desktop session, I'm getting an RDC pop-up with a name mismatch:
Reqested Remote Computer: login.company.com
Name in certificate from remote computer: TS12.company.local
It then goes on to tell me there are 2 errors: name is incorrect and not from a trusted authority.
I do not have a problem if I connect directly with the RDC client with the gateway settings enabled.
Can you point me in the right direction to resolve this?
On Corbett's comments:
What value for DefaultTSGateway have you specified in the IIS settings for the TS Web Access? This should be the same as the Common Name (CN) on the certificate that you are using on TS Gateway.
1. On the TS Web Access server, start Internet Information Services (IIS) Manager. To do this, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. In the left pane, expand the server name, expand Sites, expand Default Web Site, and then click TS.
3. In the middle pane, under ASP.NET, double-click Application Settings.
4. To change Remote Desktop Web Connection settings, modify the values in the Application Settings pane.
• To configure a default TS Gateway server, double-click DefaultTSGateway, enter the fully qualified domain name of the server in the Value box (for example, server1.contoso.com), and then click OK.
• To specify the TS Gateway authentication method, double-click GatewayCredentialsSource, type the number that corresponds to the desired authentication method in the Value box, and then click OK. The possible values include:
0 = Ask for password (NTLM)
1 = Smart card
4 = Allow user to select later
• To configure whether the Remote Desktop tab appears on the TS Web Access page, double-click ShowDesktops. In the Value box, type true to show the Remote Desktop tab, or type false to hide the Remote Desktop tab. When you are finished, click OK.
• To configure default device and resource redirection settings, double-click the setting that you want to modify (xClipboard, xDriveRedirection, xPnPRedirection, xPortRedirection, or xPrinterRedirection). In the Value box, type true to enable the redirection setting by default, or type false to disable the redirection setting by default, and then click OK.
5. When you are finished, close IIS Manager.
This has been mentioned in the step-by-step guide for TS Remote App at http://technet.microsoft.com/en-us/library/cc730673.aspx.
The certificate installed on my gateway is tsg.company.com. The value in IIS for DefaultTSGateway is set to tsg.company.com.
The requested remote computer my users connect to is login.company.com. They get the name mismatch indicating the local server name such as TS12.company.local.
Are you able to browse the site https://tsg.company.com from your clients?
Please reply back with your email id as well so that we can follow-up one on one instead of on the blog.
Yes, I can browse to that page.
cenders at homes by avi dot com
Excelent!!!! My friend, you are the expert!!!
The material in this blog is great except the questions my boss is asking I cannot answer. I have RDS gateway behind ISA 2006 and three RDS servers behind the gateway. I followed instructions for setting up the gateway behind ISA but am seriously concerned about single-sign-on. The initial gateway connection (https://rdsgateway.com) allows the client to save their password by using AutoComplete or Credential Manager. (Which is the default and how to chnage that?) Once ISA enters the picture how do the credentials get presented to the domain controller by ISA? Is it NTLM? Sure looks like it is NTLM. Now if it's NTLM inside an SSL connection that's OK. We use bridging so it is SSL to the RDS server. The big question is this? How safe are SSO credentials stored on a laptop should it get stolen? I'm assuming we will be forced to use NAP to prevent the user from caching the initial password hash. I cannot find mention of how Credential Manager stores data...
If it's just one PC that is failing to connect check that the clock is set to the right date. If date is outside cert validity date then certificate will register as expired.
Home users love to chage their clock.
I'm publishing the /rdweb path on a Server 2008 R2 server using ISA 2006.
No matter what I try, I keep getting Certificate errors, as the wildcard certificate (*.domain.com) does not match the configured gateway (rds.domain.internal).
If I configure a Gateway in RDP, it warns me of certificate errors, but connects successfully if I ignore them.
RDweb does not work at all, I can login but when clicking on Remote Desktop, it returns 'Your computer can't connect to the remote computer because the Remote Desktop Gateway server address requested and the certificate subject name do not match'.
I followed Solution 1 from here (nearly) exactly to configure: http://technet.microsoft.com/en-us/magazine/2008.09.tsg.aspx?pr=blog
For your case, obviously the wildcard certificate does not match the name with which the gateway server is published. The wildcard certificate has to be one with Cn as *.domain.internal.
Please refer the other blog on Gateway certificates http://blogs.msdn.com/rds/archive/2008/12/04/introduction-to-ts-gateway-certificates.aspx to know which versions of RDC client and which versions of ISA supports wild card certificates.
Thanks for the quick response.
According to the matrix, my configuration should be compatable. I'm running RDC 6.1 on a Windows 7 client, connecting to ISA 2006 SP1 using a trusted public CA wildcard certificate.
I can now get the Web Access to connect (after changing the gateway in RemoteApps), but it still throws Certificate errors saying the certificate presented (*.domain.com) doesn't match the configured gateway (rds.domain.internal).
Note: The internal domain and gateway has it's own certificate configured from a Private CA that never gets presented to the outside world using ISA, so as far as I can see, the external hostname is _never_ going to match the requested remote computer.
Any other ideas?
I am presuming you have RD Web Access and RD Gateway on the same machine and sharing the same certificate("rds.domain.internal"). When you try to access them from the internet you are using "rds.domain.com" . Also, I am presuming you are using the same rule to publish RD Gateway and RD Web.
If my presumptions are correct, please do the following and tell me if it resolves the issue. Open the web rule which you have created and browse to the "TO" tab. Enter "rds.domain.in" in it. In the public name tab make sure that the enrty is "rds.domain.com" i.e. the name with which the users will be connecting from outside.
Please tell me if this works. If not, can you please describe your configuration in detail so that we can help you troubleshoot.
Your assumptions are correct - the RDS Gateway and Web Access are on the same machine.
However, the 'internal' name on the "To" tab was already set correctly, and the "public" name was also set correctly.
The configuration is as follows: HTTP and HTTPS port forwarded to an ISA 2006 server with a single NIC, which publishes a single 2008 R2 Remote Desktop Server which has all RDS roles except virtual desktops (eg. web access, gateway, session host remote apps) etc.
When connecting to the public name, the wildcard certificate has no problems, but after authenticating and rying to access RD Web Access (or use the same public address as a Gateway in a RDC connection) it warns about certificate (*.domain.com) not matching the target computer.
If you receive this error: “This computer can’t connect to the remote computer because the Terminal Services Gateway server’s certificate is expired or revoked. Contact your network administrator for assistance.”
Make sure you're using correct RDP client. You need at least v6.1 (support.microsoft.com/.../en-us)
I'm using a wildcard certificate with my Remote Desktop Gateway and it works perfectly.....