Product Documentation

Transport Layer Security (TLS)

Dec 06, 2016
Configuring a XenApp or XenDesktop Site to use the Transport Layer Security (TLS) protocol includes the following procedures:
  • Obtain, install, and register a server certificate on all Delivery Controllers, and configure a port with the SSL certificate. For details, see Install TLS server certificates on Controllers.

    Optionally, you can change the ports the Controller uses to listen for HTTP and HTTPS traffic.

  • Enable TLS connections between users and Virtual Delivery Agents (VDAs) by completing the following tasks:
    Requirements and considerations:
    • Enabling TLS connections between users and VDAs is valid only for XenApp 7.6 and XenDesktop 7.6 Sites, plus later supported releases.
    • Configure TLS in the Delivery Groups and on the VDAs after you install components, create a Site, create Machine Catalogs, and create Delivery Groups.
    • To configure TLS in the Delivery Groups, you must have permission to change Controller access rules; a Full Administrator has this permission.
    • To configure TLS on the VDAs, you must be a Windows administrator on the machine where the VDA is installed.
    • If you intend to configure TLS on VDAs that have been upgraded from earlier versions, uninstall any SSL relay software on those machines before upgrading them.
    • The PowerShell script configures TLS on static VDAs; it does not configure TLS on pooled VDAs that are provisioned by Machine Creation Services or Provisioning Services, where the machine image resets on each restart.
For tasks that include working in the Windows registry:
Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

For information about enabling TLS to the Site database, see CTX137556

Note

If  both TLS and UDT are enabled at the VDA:

  • For direct access to the VDA, Citrix Receiver always uses TLS over TCP (not UDP and UDT).
  • For indirect access to the VDA using NetScaler Gateway, Citrix Receiver uses DTLS over UDP for communication with NetScaler Gateway. The communication between NetScaler Gateway and the VDA uses UDP without DTLS.  UDT is used.

Install TLS server certificates on Controllers

For HTTPS, the XML Service supports TLS features through the use of server certificates, not client certificates. To obtain, install, and register a certificate on a Controller, and to configure a port with the SSL certificate:

If the Controller has IIS installed, follow the guidance in https://technet.microsoft.com/en-us/library/cc771438%28v=ws.10%29.aspx.

If the Controller does not have IIS installed, one method of configuring the certificate is:

  1. Obtain an SSL server certificate and install it on the Controller using the guidance inhttp://blogs.technet.com/b/pki/archive/2009/08/05/how-to-create-a-web-server-ssl-certificate-manually.aspx. For information on the certreq tool, see http://technet.microsoft.com/en-us/library/cc736326(WS.10).aspx.

    If you intend to use the PowerShell script to configure TLS on VDAs, and unless you intend on specifying the SSL certificate’s thumbprint, make sure the certificate is located in the Local Computer > Personal > Certificates area of the certificate store. If more than one certificate resides in that location, the first one found will be used.

  2. Configure a port with the certificate; see http://msdn.microsoft.com/en-us/library/ms733791%28v=vs.110%29.aspx.

If the Controller is installed on Windows Server 2016, and StoreFront is installed on Windows Server 2012, a configuration change is needed at the Controller, to change the order of TLS cipher suites.

Note: This configuration change is not needed for Controller and StoreFront with other combinations of Windows Server versions.

The cipher suite order list should include the TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 cipher suites (or both);  and these cipher suites must precede any TLS_DHE_ cipher suites.

Note: Windows Server 2012 does not support the GCM ciphersuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or TLS_ECDHE_RSA_WITH_AES_128_GCM _SHA256.

Reference - Microsoft MSDN - Prioritizing Schannel Cipher Suites

  1. Using the Microsoft Group Policy Editor, browse to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.
  2. Edit the policy “SSL Cipher Suite Order”. By default, this policy is set to “Not Configured”. Set this policy to Enabled.
  3. Arrange suites in the correct order; remove any ciphersuites suites you do not want to use.

Ensure that either TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 precedes any TLS_DHE_ cipher suites.

Change HTTP or HTTPS ports

By default, the XML Service on the Controller listens on port 80 for HTTP traffic and port 443 for HTTPS traffic. Although you can use non-default ports, be aware of the security risks of exposing a Controller to untrusted networks. Deploying a standalone StoreFront server is preferable to changing the defaults.

To change the default HTTP or HTTPS ports used by the Controller, run the following command from Studio:

BrokerService.exe -WIPORT <http-port> -WISSLPORT <https-port>

where <http-port> is the port number for HTTP traffic and <https-port> is the port number for HTTPS traffic.

Note: After changing a port, Studio might display a message about license compatibility and upgrading. To resolve the issue, re-register service instances using the following PowerShell cmdlet sequence:

Get-ConfigRegisteredServiceInstance -ServiceType Broker
-Binding  XML_HTTPS |
Unregister-ConfigRegisteredServiceInstance 

Get-BrokerServiceInstance | where Binding -eq "XML_HTTPS" |  
Register-ConfigServiceInstance

Enforce HTTPS traffic only

If you want the XML Service to ignore HTTP traffic, create the following registry setting in HKLM\Software\Citrix\DesktopServer\ on the Controller and then restart the Broker Service.

To ignore HTTP traffic, create DWORD XmlServicesEnableNonSsl and set it to 0.

There is a corresponding registry DWORD value you can create to ignore HTTPS traffic: DWORD XmlServicesEnableSsl. Ensure that it is not set to 0.

TLS settings on VDAs

A Delivery Group cannot have a mixture of some VDAs with TLS configured and some VDAs without TLS configured. When you configure TLS for a Delivery Group, you should have already configured TLS for all of the VDAs in that Delivery Group

When you configure TLS on VDAs, permissions on the installed SSL certificate are changed, giving the ICA Service read access to the certificate’s private key, and informing the ICA Service of the following:

  • Which certificate in the certificate store to use for TLS.
  • Which TCP port number to use for TLS connections.

The Windows Firewall (if enabled) must be configured to allow incoming connection on this TCP port. This configuration is done for you when you use the PowerShell script.

  • Which versions of the TLS protocol to allow.

Important: Citrix recommends that you review your use of SSLv3, and reconfigure those deployments to remove support for SSLv3 where appropriate. See CTX200238.

The supported TLS protocol versions follow a hierarchy (lowest to highest): SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2. You specify the minimum allowed version; all protocol connections using that version or a higher version are allowed.

For example, if you specify TLS 1.1 as the minimum version, then TLS 1.1 and TLS 1.2 protocol connections are allowed. If you specify SSL 3.0 as the minimum version, then connections for all the supported versions are allowed. If you specify TLS 1.2 as the minimum version, only TLS 1.2 connections are allowed.

  • Which TLS cipher suites to allow.

A cipher suite selects the encryption that will be used for a connection.  Clients and VDAs can support different sets of cipher suites. When a client (Citrix Receiver or StoreFront) connects and sends a list of supported TLS cipher suites, the VDA matches one of the client’s cipher suites with one of the cipher suites in its own list of configured cipher suites, and accepts the connection. If there is no matching cipher suite, the VDA rejects the connection.

Three sets of cipher suites (also known as compliance modes) are supported by the VDA: GOV(ernment), COM(mercial), and ALL. The acceptable cipher suites also depend on the Windows FIPS mode; see http://support.microsoft.com/kb/811833 for information about Windows FIPS mode. The following table lists the cipher suites in each set:

TLS cipher suite

GOV

COM

ALL

GOV

COM

ALL

FIPS mode

Off

Off

Off

On

On

On

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

x

 

x

x

 

x

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

x

 

x

x

 

x

TLS_RSA_WITH_AES_256_GCM_SHA384

x

 

x

x

 

x

TLS_RSA_WITH_AES_128_GCM_SHA256

x

x

x

x

x

x

TLS_RSA_WITH_AES_256_CBC_SHA256

x

 

x

x

 

x

TLS_RSA_WITH_AES_256_CBC_SHA

x

 

x

x

 

x

TLS_RSA_WITH_AES_128_CBC_SHA

 

x

x

 

x

x

TLS_RSA_WITH_RC4_128_SHA

 

x

x

 

 

 

TLS_RSA_WITH_RC4_128_MD5

 

x

x

 

 

 

TLS_RSA_WITH_3DES_EDE_CBC_SHA

x

 

x

x

 

x

 

Important: An additional step is necessary when the VDA is on a Windows Server 2016 or later, or Windows 10 Anniversary Edition or later.  This affects connections from Citrix Receiver for Windows 4.6.

On the VDA (Windows Server 2016 or Windows 10 Anniversary Edition or later), using the Group Policy Editor, go to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. Select the following order:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Note: The first four items also specify the elliptic curve, P384 or P256. Ensure that "curve25519" is not selected.  FIPS Mode does not prevent the use of "curve25519".

When this Group Policy setting is configured, the VDA will select a cipher suite only if appears in both lists: the Group Policy list and the list for the selected compliance mode (COM, GOV, or ALL). The cipher suite must also appear in the list sent by the client (Citrix Receiver or StoreFront).

This Group Policy configuration also affects other TLS applications and services on the VDA.   If your applications require specific cipher suites, you may need to add them to this Group Policy list.

Configure TLS on a VDA using the PowerShell script

The Enable-VdaSSL.ps1 script enables or disables the TLS listener on a VDA. This script is available in the Support >Tools > SslSupport folder on the installation media.

When you enable TLS, the script disables all existing Windows Firewall rules for the specified TCP port before adding a new rule that allows the ICA Service to accept incoming connections only on the TLS TCP port. It also disables the Windows Firewall rules for:
  • Citrix ICA (default: 1494)
  • Citrix CGP (default: 2598)
  • Citrix WebSocket (default: 8008)

The result is that users can connect only over TLS; they cannot use raw ICA, CGP, or WebSocket to connect.

The script contains the following syntax descriptions, plus additional examples; you can use a tool such as Notepad++ to review this information.

You must specify either the –Enable or –Disable parameter; all other parameters are optional.

Syntax

Enable-VdaSSL {-Enable | -Disable} [–SSLPort <port>] [-SSLMinVersion "<min-ssl-version>"] [-SSLCipherSuite"<suite>"] [-CertificateThumbPrint "<thumbprint>"]

Parameter Description
-Enable Installs and enables the TLS listener on the VDA. Either this parameter or the –Disable parameter is required.
-Disable Disables the TLS listener on the VDA. Either this parameter or the –Enable parameter is required. If you specify this parameter, no other parameters are valid.
–SSLPort <port> TLS port. Default: 443
-SSLMinVersion "<min-ssl-version>"

Minimum TLS protocol version, enclosed in quotation marks. Valid values: "SSL_3.0", "TLS_1.0", "TLS_1.1", and "TLS_1.2". Default: "TLS_1.0"

Important: Citrix recommends that customers review their usage of SSLv3 and take steps to reconfigure their deployments to remove support for SSLv3 where appropriate. See CTX200238.

-SSLCipherSuite "<suite>" TLS cipher suite, enclosed in quotation marks. Valid values: "GOV", "COM", and "ALL". Default: "ALL"
-CertificateThumbPrint "<thumbprint>" Thumbprint of the SSL certificate in the certificate store, enclosed in quotation marks. This parameter is generally used when the certificate store has multiple certificates; the script uses the thumbprint to select the certificate you want to use. Default: the first available certificate found in the Local Computer > Personal > Certificates area of the certificate store.

Examples

The following script installs and enables the TLS 1.2 protocol version value.
Enable-VdaSSL –Enable
The following script installs and enables the TLS listener, and specifies TLS port 400, the GOV cipher suite, and a minimum TLS 1.2 protocol value.
Enable-VdaSSL – Enable –SSLPort 400 'SSLMinVersion "TLS_1.2"  
–SSLCipherSuite "GOV"
The following script disables the TLS listener on the VDA.
Enable-VdaSSL –Disable

Manually configure TLS on a VDA

When configuring TLS on a VDA manually, you grant generic read access to the TLS certificate's private key for the appropriate service on each VDA: NT SERVICE\PorticaService for a VDA for Windows Desktop OS, or NT SERVICE\TermService for a VDA for Windows Server OS. On the machine where the VDA is installed:
  1. Launch the Microsoft Management Console (MMC): Start > Run > mmc.exe.
  2. Add the Certificates snap-in to the MMC:
    1. Select File > Add/Remove Snap-in.
    2. Select Certificates and then click Add.
    3. When prompted with "This snap-in will always manage certificates for:" choose "Computer account" and then click Next.
    4. When prompted with "Select the computer you want this snap-in to manage" choose "Local computer" and then click Finish.
  3. Under Certificates (Local Computer) > Personal > Certificates, right–click the certificate and then select All Tasks > Manage Private Keys.
  4. The Access Control List Editor displays "Permissions for (FriendlyName) private keys" where (FriendlyName) is the name of your SSL certificate. Add one of the following services and give it Read access:
    • For a VDA for Windows Desktop OS, "PORTICASERVICE"
    • For a VDA for Windows Server OS, "TERMSERVICE"
  5. Double-click the installed SSL certificate. In the certificate dialog, select the Details tab and then scroll to the bottom. Click Thumbprint.
  6. Run regedit and go to HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd.
    1. Edit the SSL Thumbprint key and copy the value of the SSL certificate’s thumbprint into this binary value. You can safely ignore unknown items in the Edit Binary Value dialog box (such as '0000' and special characters).
    2. Edit the SSLEnabled key and change the DWORD value to 1. (To disable SSL later, change the DWORD value to 0.)
    3. If you want to change the default settings (optional), use the following in the same registry path:
      • SSLPort DWORD – SSL port number. Default: 443.
      • SSLMinVersion DWORD – 1 = SSL 3.0, 2 = TLS 1.0, 3 = TLS 1.1, 4 = TLS 1.2. Default: 2 (TLS 1.0).
      • SSLCipherSuite DWORD – 1 = GOV, 2 = COM, 3 = ALL. Default: 3 (ALL).
  7. Ensure the TLS TCP port is open in the Windows Firewall if it is not the default 443. (When you create the inbound rule in Windows Firewall, make sure its properties have the "Allow the connection" and "Enabled" entries selected.)
  8. Ensure that no other applications or services (such as IIS) are using the TLS TCP port.
  9. For VDAs for Windows Server OS, restart the machine for the changes to take effect. (You do not need to restart machines containing VDAs for Windows Desktop OS.)

Configure TLS on Delivery Groups

Complete this procedure for each Delivery Group that contains VDAs you have configured for TLS connections.
  1. From Studio, open the PowerShell console.
  2. Run asnp Citrix.* to load the Citrix product cmdlets.
  3. Run Get-BrokerAccessPolicyRule -DesktopGroupName '<delivery-group-name>' | Set-BrokerAccessPolicyRule -HdxSslEnabled $true.

    where <delivery-group-name> is the name of the Delivery Group containing VDAs.

  4. Run Set-BrokerSite -DnsResolutionEnabled $true.

Troubleshooting

If a connection error occurs, check the VDA's system event log.

When using Receiver for Windows, if you receive a connection error (such as 1030) that indicates an TLS error, disable Desktop Viewer and then try connecting again; although the connection will still fail, an explanation of the underlying TLS issue might be provided (for example, you specified an incorrect template when requesting a certificate from the certificate authority).

Communication between Controller and VDA

Communication between the Controller and the VDA is secured by Windows Communication Framework (WCF) message-level protection. Additional transport-level protection using TLS is not required. The WCF configuration uses Kerberos for mutual authentication between the Controller and VDA. Encryption uses AES in CBC mode with a 256-bit key. Message integrity uses SHA-1.

According to Microsoft, the Security protocols used by WCF conform to standards from OASIS (Organization for the Advancement of Structured Information Standards), including WS-SecurityPolicy 1.2.  Additionally, Microsoft states that WCF supports all algorithm suites listed in Security Policy 1.2.

Communication between the Controller and VDA uses the basic256 algorithm suite, whose algorithms are as stated above.

TLS and HTML5 video redirection

HTML5 video redirection includes support for video content over TLS (HTTPS).  To achieve this, custom certificates are placed in the computer's certificate store on the VDA.

HTML5 video redirection is disabled by default. 

If you do not intend to use HTML5 video redirection with video content over TLS,  Citrix recommends that you delete the two certificates from the Trusted Root Certificates store on the VDA.  These certificates are Issued to "Citrix HDX"/Issued by "Citrix HDX", and Issued to "127.0.0.1"/Issued by "Citrix HDX".

Citrix recommends deleting the files libeay32.dll and ssleay32.dll from the HTML5 Video Redirection installation folder. This is recommended practice even if you do not intend to use HTML5 video content.

For more information on HTML5 video redirection, see Multimedia policy settings.