RDP file signing is all about security.  When you sign RDP files with trusted certificates, your clients can verify that important settings such as which server to connect to haven’t changed since the creation of the RDP file. This helps protect both the user and the server from potential attacks.  As an added benefit, because the identity of the publisher can be determined, the client doesn’t need to display warning dialogs stating that the RDP file might not be safe.

So how do you get all this goodness for your users?

You can create signed RDP files using the RemoteApp manager tool, but if you’re looking for a scripted approach this isn’t practical.  Luckily, there’s a tool that helps sign RDP files in a script called rdpsign.exe.  Unfortunately, it shipped without the ability to write out the Unicode header, but this is easily fixed with vbscript and has been fixed in the next release of Windows. 

So how do you sign using rdpsign? 

First, create or import the certificate that you are going to be using.  You can find more information on how to set up the certificates here:  http://technet.microsoft.com/en-us/library/cc754499.aspx.  

Second, get the thumbprint by looking at the certificates, clicking the Details tab, and then scrolling to the bottom. Keep in mind that the command line tool assumes there are no spaces in the thumbprint. 

Third, sign the file with rdpsign.exe.   You can find more information on the command line use of the tool here: http://technet.microsoft.com/en-us/library/cc753982.aspx.  This will sign the rdp file, but when you double-click it, the mstsc dialog box will open with incorrect settings. This is because mstsc is trying to read the file as ASCII and it is encoded in Unicode.  This bug has been fixed in the next release of Windows 7.

Finally, to fix this encoding issue, you can save the vb-script below and run the script on the file (for example: “fixsignRdp.vbs mySignedFile.rdp”).  This script reads the file in as Unicode and writes it back out with the Unicode Byte-Order Mark.  Then the RDP file will be signed and ready for anyone to use.

Cheers,
Kevin London

fixsignRdp.vbs

' This script will read in the file as Unicode
' and then write the file back out as Unicode.
' The issue is that the file is missing the Unicode header
' and forcing the re-write adds this to the file.
Dim argCount:argCount = Wscript.Arguments.CountIf (argCount < 1) Then
        Wscript.Echo "Usage: fixRdpSignature <rdpPath>"
        Wscript.Quit 1
End Ifpath = Wscript.Arguments(0)Dim fso,rdpFileSet
fso = CreateObject("Scripting.FileSystemObject")
Set rdpFile = fso.OpenTextFile(path,1, 0, -1)
rdpContents = rdpFile.ReadAll()
rdpFile.Close
Set rdpFile = fso.OpenTextFile(path, 2, 0, -1)
rdpFile.Write rdpContents
rdpFile.Close

With Microsoft App-V 4.5, and with SoftGrid 4.2 along with the MSI utility , we now have the ability to create and distribute standalone virtual apps that require no server or streaming infrastructure whatsoever.  While this gives tremendous flexibility...(read more)

This is the third and final part of our recent series on configuring certificates on TS Gateway. See also Part I and Part II

Background

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:

Resolution -

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:

http://technet.microsoft.com/en-us/library/cc754252.aspx

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:

http://technet.microsoft.com/en-us/library/cc754252.aspx

Note: If you continue facing issues while trying to bind the TS Gateway certificate – refer to the following KB:

http://support.microsoft.com/kb/959120/

For information on why TS Gateway needs a certificate and which is the recommended certificate to use on TS Gateway, see the first post in this series.

To deploy a certificate on TS Gateway server, you must have the server certificate (and private key) contained in a file. You must also have access to the Certificates snap-in and have it set to view computer certificates from the local computer (though this can be done remotely).

This blog will take you through the following steps. Please note that the screenshots in this blog are applicable to Windows Server 2008 only.

1. Viewing the certificate store on the local computer
2. Installing the certificate in the personal certificate store of the local computer
3. Installing the certificate on TS Gateway
4. A common issue when deploying a certificate on TS Gateway
5. How to trust the TS Gateway certificate on the clients

Viewing the certificate store on the local computer

To view the Certificates store on the local computer, follow these steps:

1. Click Start, and then click Run.

2. Type "MMC.EXE" (without the quotation marks), and then click OK.

3. Click File menu item in the new MMC you created, and then click Add/Remove Snap-in.

4. Click the Certificates snap-in, and then click Add.

5. Choose the Computer account option and click Next.

6. Select Local Computer on the next screen, and then click Finish.

7. Click OK.

8. You have now added the Certificates snap-in, which will allow you to work with any certificates in your computer's certificate store. You may want to save this MMC for later use.

Now that you have access to the Certificates snap-in, you can import the server certificate into your computer's certificate store by following the steps in the next section.

Installing the certificate in the personal certificate store of the local computer

1. Open the Certificates (Local Computer) snap-in and navigate to Personal, and then Certificates.

Note: Certificates may not be listed. If it is not, that is because there are no certificates installed.

2. Right-click Certificates (or Personal if that option does not exist.)

3. Choose All Tasks, and then click Import.

4. When the wizard starts, click Next. Browse to the PFX file you created containing your server certificate and private key. Click Next.

5. Enter the password you gave the PFX file when you created it. Be sure the Mark the key as exportable option is selected if you want to be able to export the key pair again from this computer. As an added security measure, you may want to leave this option unchecked to ensure that no one can make a backup of your private key.

6. Click Next, and then choose the Certificate Store you want to save the certificate to. You should select Personal because it is a server certificate. If you included the certificates in the certification hierarchy, it will also be added to this store.

7. Click Next. You should see a summary screen showing what the wizard is about to do. If this information is correct, click Finish.

8. You will now see the server certificate you just installed in the list of personal certificates. It will be denoted by the common name of the server (found in the subject section of the certificate).

Now that you have the certificate backup imported into the certificate store, you can use the TS Gateway Manager UI to install the certificate on TS Gateway. The steps for doing this are outlined in the next section.

Installing the certificate on TS Gateway

1. Click Start, click Administrative Tools, click Terminal Services, and then click TS Gateway Manager.

Right-click on the <Machine Name> and select Properties.

2. On the SSL Certificate tab, click Select an existing certificate for SSL encryption (recommended), and then click Browse Certificates.

3. Choose the certificate, and then click Install.

4. Click OK.

A common issue when deploying a certificate on TS Gateway

The most common issue faced by a TS Gateway administrator is that, although he has installed the certificate in the certificate store of the gateway machine, he is not able to view and install the certificate through the TS Gateway snap-in. Possible causes of this are:

1. The certificate does not have the private keys:

If you install the certificate without the private keys in the Personal Certificate Store of the Local Computer, then you can’t view the certificate on the Browse Certificate window of the TS Gateway Manager UI and therefore can’t install it for TS Gateway. This is how a certificate without a private key looks in the Certificate Manager UI. Notice that the first certificate (Issued to: www.contoso.com) does not have a key symbol over its icon.

2. The certificate is not installed in the personal certificate store of the local computer:

If you install the certificate in the personal certificate store of User instead of the personal certificate store of Local Computer, then you can’t view the certificate on the Browse Certificate window on the TS Gateway Manager UI and therefore can’t install it for TS Gateway.

3. The certificate is not a “Server Authentication” certificate:

If the “Intended Purpose” of the certificate is not “Server Authentication” then it won’t appear in the list of available certificates that can be installed on TS Gateway on the Browse Certificate window of the TS Gateway Manager UI. The following example shows how to view the “Intended Purpose.”

The general rule of thumb is that if you have installed the certificate but still don’t see it in the Browse Certificate window of the TS Gateway Manager UI, ensure that you have private keys installed for the certificate and that you have installed the certificate in the personal certificate store of the local computer instead of the User certificate store and that the certificate is intended for “Server Authentication.”

How to trust the TS Gateway certificate on the clients

When you are using a self-signed or private CA certificate on the TS Gateway, the clients won’t trust the TS Gateway certificate by default. In this case, follow the steps outlined in the blog at http://blogs.technet.com/sbs/archive/2008/10/03/receiving-certificate-errors-when-connecting-to-clients-servers-with-ts-gateway-or-remote-web-workplace-on-sbs-2008.aspx.

One of the great things about SoftGrid/App-V is that it's so easy to shoot out apps to client machines and automatically populate the user's desktop or Start menu with the appropriate icons, but if you're using mandatory profiles this may not work as...(read more)

Hi Everyone, The Application Virtualization team would like to get your input and ask you to help us with our planning process. We’d like your insight to help us improve SERVER application serviceability, reliability, and availability to create a consistent...(read more)

Here's another issue we saw during the App-V 4.5 beta that you might run across when installing the client.  The resolution may seem obvious but the error can be confusing because it won't come right out and tell you that you don't have enough drive...(read more)

Here's another solution from Steve Thomas, our friendly neighborhood App-V beta engineer.  This time he brings news on how we can now virtualize Adobe Photoshop 7.x using Microsoft App-V 4.5: ======== Issue: When you attempt to run a virtualized...(read more)

Here's another issue we saw a couple times during the App-V 4.5 beta. It's probably something that would be fairly uncommon but in case you're having trouble restarting a Microsoft Application Virtualization Streaming Server after it's been stopped then...(read more)

Here's another great tip from Steve Thomas, this time concerning the search function in Outlook 2007 when streamed to Windows Vista clients: ======== Issue: When Microsoft Outlook 2007 is sequenced and streamed with Windows Vista, the search function...(read more)

Here's another tip from Steve Thomas, esteemed 4.5 beta engineer.  This one involves a specific error you may receive when sequencing Microsoft Visual C# 2005 Express Edition based applications: ======== Issue: When a virtualized Microsoft Visual...(read more)

Here are some tips on sequencing various Windows Live components that was originally written up by our very own Terry McKinney. If you have plans for sequencing any of the Windows Live apps you'll want to read through this first: ======== This article...(read more)

Here's another one we ran across during the Microsoft App-V 4.5 beta.  If you're having trouble sequencing the Safari browser then this one's for you: ======== Issue: When attempting to sequence Apple Safari 3.1, the package hangs after the shortcut...(read more)

For the week of 11-30 through 12-6 we had three new Knowledge Base articles on Microsoft App-V.  Links and titles are below: ======== http://support.microsoft.com/?kbid=960782 When upgrading to Vista SP2 from XP, you may get an Application Compatibility...(read more)

Here's another tip from Steve Thomas that he found during the 4.5 beta.  This is probably not something you'd run into on a regular basis but I wanted to mention it just in case: ======== Issue: You may receive the following error message (0e-00002015)...(read more)

Here's another App-V 4.5 issue we saw during the beta.  This one was written up by Steve Thomas and concerns how to properly specify the SQL instance you want to use for the App-V 4.5 Management Server during installation.  If you're not using...(read more)

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.

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):

1. 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.
2. 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.
3. 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.

I was browsing through the dark corners of some internal Microsoft App-V doc repositories the other day and came across a cool recipe for sequencing Microsoft Money 2007 that I thought you might be interested in seeing.  This was originally submitted...(read more)

Here are some more KBs for you.  For the week of 11-23 through 11-29 we had two new Knowledge Base articles on Microsoft Application Virtualization 4.5.  Links and titles are below: ======== SoftGrid 4.5 for Win Desktop AL 959692 - The installation...(read more)

The App-V team is happy to announce the availability of prescriptive guidance for sequencing Visual Studio 2008 in Microsoft Application Virtualization 4.5. The prescriptive guidance describes one method that you can use to sequence Microsoft Visual Studio...(read more)