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.
http://www.microsoft.com/learning/en/us/books/12716.aspx
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):
- SSL initiation - The client and server exchange cryptographic information such as SSL version number, cipher settings, session data, and other information needed to establish a SSL connection. In this stage, the TS Gateway server sends its X.509 SSL certificate, which is used by the client to authenticate.
- Gateway authentication & session key generation – The client validates the server identity using the SSL certificate produced by the TS Gateway. If the TS Gateway server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the TS Gateway server can be authenticated successfully, the client creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 1), and then sends the encrypted pre-master secret to the server. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
- Establishing encrypted session - If the server has requested client authentication, the server attempts to authenticate the client. If TS Gateway is configured to authenticate users using smartcard, then client authentication is enforced during the SSL handshake. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection). The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
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:
|
Certificate type |
RDC 6.0 on the client |
RDC 6.1 and above on the client |
With ISA on the edge |
|
Self-signed |
Yes |
Yes |
Yes |
|
Public CA |
Yes |
Yes |
Yes |
|
Private CA |
Yes |
Yes |
Yes |
|
Wildcard certificates |
No |
Yes |
Yes (ISA 2006 and later) |
|
Certificate with Subject Alternative Name (SAN) |
No |
Yes |
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)
References:
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.