Where virtual desktops need certificate management

Web-based applications

Unless you have been living under a rock, you know that one of the biggest trends in IT at the moment is that many applications are being moved to the cloud. Even if you run all your applications on-premises, there is a good chance that many of them are Web-enabled so that they can be accessed through a Web browser.

Most application Web interfaces use Secure Sockets Layer (SSL) encryption to keep sensitive data secure. SSL encryption is certificate-based, but the X.509 certificate that is required by the encryption process is installed onto the Web server that hosts the application, not the client computer or the virtual desktop. However, this does not mean that there are no certificate requirements for virtual desktops.

When a browser attempts to establish an SSL session with a Web server, the browser checks the server's certificate to make sure it's valid, has not expired and is from a trustworthy source. If the certificate has expired or if it appears to have come from a dubious source, then the browser will display an error message when the user attempts to access the encrypted page.

Windows desktop operating systems are preconfigured to trust well-known commercial (public) certificate authorities (CAs). However, not all Web-based applications use certificates that are issued by a widely trusted authority. This is particularly true for applications that are hosted on-premises.

For example, Exchange Server provides a Web-based interface called Outlook Web App. The last few versions of Exchange Server have been configured by default to use a self-signed certificate, but self-signed certificates are not trusted by virtual desktops. As such, Microsoft recommends replacing the self-signed certificate with a certificate issued either by a public certificate authority or by an enterprise certificate authority.

Some organizations choose to configure Windows Server to act as an enterprise certificate authority. Doing so gives you the freedom to issue certificates on an as-needed basis without having to incur the cost of purchasing certificates from a public certificate authority. As is the case with self-signed certificates, however, certificates that are issued by an enterprise certificate authority will not be trusted by the virtual desktops. Here's how to solve that problem:

Figure 1. The certificate authority's certificate must be added to the Trusted Root Certification Authority list on your virtual desktops.

Download a CA certificate from the enterprise certificate authority and add it to the virtual desktop's Trusted Root Certification Authorities list (Figure 1). As an alternative, you can have your internally issued certificate co-signed by a public certificate authority that participates in Microsoft's Root Certification Program Members program.

Using certificates for connectivity

In Microsoft-based VDI environments, RDP files are used to connect Windows clients to virtual desktops or RemoteApp applications. Although the RDP files will work without a certificate, Microsoft recommends using a certificate to digitally sign any RDP files. That provides verifiable proof that the RDP file was issued by the organization and that it is not a counterfeit file that provides connectivity to a malicious host.

Although digitally signing RDP files is a good idea, there are a few limitations that you need to be aware of. First, only Windows clients use RDP files. Furthermore, users can only connect to their virtual desktop using a digitally signed RDP file if they are working from a device that uses version 6.1 or higher, or Microsoft's Remote Desktop Client.

Figure 2. You can use Group Policy to force Windows clients to check the digital signature on RDP files.

If you are going to go through the trouble of digitally signing your RDP files, it's a good idea to configure the remote desktop client machines to look for the signature. If the client computers are domain members, then you can use Group Policy to accomplish this. If not, you can modify the local security policy.

The policy setting that controls connectivity behavior is located at: Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client. The "Specify SHA1 thumbprints of certificates representing trusted RDP publishers" setting can be used to specify trusted sources of RDP files (Figure 2). You will also need to disable the "Allow .RDP files from unknown publishers" setting.

Just beware that modifying a local security policy may be very difficult to do in BYOD environments.