Why does TS Gateway need a certificate?
A TS Gateway certificate is used for authentication and secure communication purposes by the TS clients. To appreciate the purpose of TS Gateway certificates, you will need to understand SSL communication. As illustrated in the following diagram and described in the steps below, a TS client launches an HTTP-SSL connection to the TS Gateway, which begins with a SSL handshake. The handshake allows the server to authenticate itself to the client by using public-key techniques, and then allows the client and server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.
Illustration borrowed from Windows Server 2008 Terminal Services Resource Kit, available here.
The steps involved in the SSL handshake are as follows (note that the following steps assume the use of the cipher suites listed in Cipher Suites with RSA Key Exchange: Triple DES, RC4, RC2, DES):
What type of X.509 certificate can the TS Gateway work with?
X.509 certificates can be self-signed, also known as self-issued, or issued by an X.509 Certification Authority (CA). An X.509 CA is either a third-party public certification authority that issues certificates or a public key infrastructure (PKI) that is deployed within your organization. Unless otherwise noted specifically, this topic refers to both solutions as certification authorities (CA). Third-party public CAs are known as public CAs. For complete specifications about the kind of certificate that can be used on TS Gateway server, please refer to the “Certificates requirements for TS Gateway” section in the TS Gateway step-by-step guide at http://technet.microsoft.com/en-us/library/cc754252.aspx#BKMK_ObtainCertTSGateway .
How do I know which type of X.509 certificate is better?
1. Public CA certificate: Windows and various third-party operating systems include a set of built-in third-party public root CAs. If you trust the certificates issued by these third-party public root CAs, you can verify certificates issued by these CAs.
Trust is automatic if the following conditions are true:
1. Your organization uses the default Windows installation
2. The client software used in your organization also trusts the built-in third-party public root CAs
In this case, additional trust configuration is not required. Therefore, this is the recommended certificate option for TS Gateway.
2. Private CA certificate: A private trusted root CA is a root CA that has been deployed by a private or internal PKI. For example, when your organization has deployed an internal PKI with its own root certificate, you must make additional trust configurations. It is not a best practice to use certificates issued by a private PKI for TS Gateway that support external connections into your organization.
When a private root CA is used, you must update the Windows Trusted Root certificate store on all user devices where certificate authentication is required.
3. Self-signed certificate: The TS Gateway snap-in provides the admin a way to create a self-signed certificate and use it for TS Gateway. A self-signed certificate costs essentially nothing, but it does have the following disadvantage.
Self-signed certificates are not trusted by default on the clients. The admin will have the added responsibility of distributing the certificates to the clients, and the clients need to put the certificates in their “Trusted” Certificate store, which can become a tedious task and is prone to mistakes.
Using self-signed certificates on TS Gateway is not recommended.
Does TS Gateway support wildcard and SAN certificates?
Yes, TS Gateway does support wildcard certificates and Subject Alternative Name (SAN) certificates. The following matrix lists all the different types of supported certificates along with the client support and ISA support cases as well.
Certificates that can be used on TS Gateway:
RDC 6.0 on the client
RDC 6.1 and above on the client
With ISA on the edge
Yes (ISA 2006 and later)
Certificate with Subject Alternative Name (SAN)
Yes for ISA 2006 SP1
No* for ISA 2004 and 2006
* ISA Server 2004 cannot process certificate SAN attributes at all. The Subject of the certificate installed at the published server must match the published host name used in the Web Publishing rule. ISA Server 2006 is able to use either the Subject or the first SAN entry. What this means for the ISA server admin is that if the ISA server is expecting the certificate to read “contoso.com,” that name should be either of the following:
1. The certificate “Subject” (AKA “common name”)
2. The first entry in the SAN list (ISA Server 2006 only)
RDC: Remote Desktop Client. To check the version of the RDC client, check the information at the link http://technet.microsoft.com/en-us/library/cc736828.aspx
Wildcard certificate: A Wildcard Certificate allows you to secure multiple sub-domains on one domain on the same server using *.domain.com pattern for the common name (CN). For example, while a certificate for contoso.microsoft.com will not work for fabrikam.microsoft.com, a certificate with CN = *.microsoft.com will be valid for both.
Subject Alternative Name (SAN): Subject Alternative Names allow you to specify a list of host names to be protected by a single SSL certificate. A certificate with SAN entries for both contoso.microsoft.com and fabrikam.microsoft.com will work with both servers.
Après avoir publié mon précédent billet, l' équipe en charge du développement de Terminal Server
For information on why TS Gateway needs a certificate and which is the recommended certificate to use
This is the third and final part of our recent series on configuring certificates on TS Gateway. See
How about from the Gateway to the internal TS Farm. Will the connections be encrypted? If yes, that certificate should be from public ca?
Is there a step by step guide to create a CA signed certificate for the TS Gateway ? I've followed the documents on MS website, obtaining cetificate for the Gateway, and could not get this work, except self-signed certificate.
@Steve -- here is the information to obtain a server authentication certificate from your enterprise CA: http://technet.microsoft.com/en-us/library/cc740173(WS.10).aspx
Thanks for the response.
My firm does not manage CA, so I need to get a third party CA signed the certificate. Thus, I need a guide to generate CSR for the Gateway.
@Steve -- you need to put a request to one of the third party CAs to get you a server authentication certificate. The certificate requirements for RD Gateway can be found on the step by step guide at http://technet.microsoft.com/en-us/library/cc754252(WS.10).aspx#BKMK_ObtainCertTSGateway
To get information on Windows root certificate program members, please refer this: http://support.microsoft.com/kb/931125