Product Documentation


Feb 16, 2015

In this article:

To secure the communication between your server farm and Citrix Receiver, you can integrate your Citrix Receiver connections to the server farm with a range of security technologies, including:

  • A SOCKS proxy server or secure proxy server (also known as security proxy server, HTTPS proxy server, or TLS tunneling proxy server). You can use proxy servers to limit access to and from your network and to handle connections between Receiver and servers. Receiver supports SOCKS and secure proxy protocols.
  • Secure Gateway or SSL Relay solutions with Transport Layer Security (TLS) protocols. TLS versions 1.0 through 1.2 are supported.
  • A firewall. Network firewalls can allow or block packets based on the destination address and port. If you are using Receiver through a network firewall that maps the server's internal network IP address to an external Internet address (that is, network address translation, or NAT), configure the external address.

Connecting through a proxy server

Proxy servers are used to limit access to and from your network, and to handle connections between Citrix Receiver and your Citrix XenApp or Citrix XenDesktop deployment. Citrix Receiver supports the SOCKS protocol, along with the Secure Gateway and Citrix SSL Relay, the secure proxy protocol, and Windows NT Challenge/Response (NTLM) authentication.

The list of supported proxy types is restricted by the contents of Trusted_Regions.ini and Untrusted_Regions.ini to the Auto, None, and Wpad types. If you need to use the SOCKS, Secure or Script types, edit those files to add the additional types to the permitted list.

Note: To ensure a secure connection, enable TLS.

Connecting through a secure proxy server

Configuring connections to use the secure proxy protocol also enables support for Windows NT Challenge/Response (NTLM) authentication. If this protocol is available, it is detected and used at run time without any additional configuration.

Important: NTLM support requires that the OpenSSL library,, is installed on the user device. This library is often included in Linux distributions, but can be downloaded from if required.

Connecting with the Secure Gateway or Citrix Secure Sockets Layer Relay

You can integrate Receiver with the Secure Gateway or Secure Sockets Layer (SSL) Relay service. Receiver supports the TLS protocol.TLS (Transport Layer Security) is the latest, standardized version of the SSL protocol. The Internet Engineering Taskforce (IETF) renamed it TLS when it took over responsibility for the development of SSL as an open standard. TLS secures data communications by providing server authentication, encryption of the data stream, and message integrity checks. Some organizations, including U.S. government organizations, require the use of TLS to secure data communications. These organizations may also require the use of validated cryptography, such as FIPS 140 (Federal Information Processing Standard). FIPS 140 is a standard for cryptography.

Connecting with the Secure Gateway

You can use the Secure Gateway in either Normal mode or Relay mode to provide a secure channel for communication between Receiver and the server. No configuration of Receiver is required if you are using the Secure Gateway in Normal mode and users are connecting through the Web Interface.

Receiver uses settings that are configured remotely on the server running the Web Interface to connect to servers running the Secure Gateway. For information about configuring proxy server settings for Receiver, see the Web Interface documentation.

If the Secure Gateway Proxy is installed on a server in the secure network, you can use the Secure Gateway Proxy in Relay mode. For more information, see the XenApp (Secure Gateway) documentation.

If you are using Relay mode, the Secure Gateway server functions as a proxy and you must configure Receiver to use:

  • The fully qualified domain name (FQDN) of the Secure Gateway server.
  • The port number of the Secure Gateway server. Note that Relay mode is not supported by Secure Gateway Version 2.0.
The FQDN must list, in sequence, the following three components:
  • Host name
  • Intermediate domain
  • Top-level domain

For example: is an FQDN, because it lists, in sequence, a host name (my_computer), an intermediate domain (my_company), and a top-level domain (com). The combination of intermediate and top-level domain ( is generally referred to as the domain name.

Connecting with Citrix SSL Relay

By default, Citrix SSL Relay uses TCP port 443 on the XenApp server for TLS-secured communication. When the SSL Relay receives a TLS connection, it decrypts the data before redirecting it to the server, or, if the user selects SSL/TLS+HTTPS browsing, to the Citrix XML Service.

If you configure SSL Relay to listen on a port other than 443, you must specify the non-standard listening port number to Receiver.

You can use Citrix SSL Relay to secure communications:

  • Between a TLS-enabled user device and a server
  • With Web Interface, between the XenApp server and the web server

For information about configuring and using SSL Relay to secure your installation, see the XenApp documentation. For information about configuring the Web Interface to use TLS encryption, see the Web Interface documentation.

Configuring and enabling TLS

You can control the versions of the TLS protocol that can be negotiated by adding the following configuration options in the [WFClient] section:

  • MinimumTLS=1.0
  • MaximumTLS=1.2

These are the default values, which are implemented in code. Adjust them as you require.

Note: These values will be read whenever programs start. If you change them after starting selfservice or storebrowse you should type: killall AuthManagerDaemon ServiceRecord selfservice storebrowse. 

Note: This version of Receiver for Linux disables the use of the SSLv3 protocol.

Installing root certificates on user devices

To use TLS, you need a root certificate on the user device that can verify the signature of the Certificate Authority on the server certificate. By default, Receiver supports the following certificates.
Certificate Issuing Authority
Class4PCA_G2_v2.pem VeriSign Trust Network
Class3PCA_G2_v2.pem VeriSign Trust Network
BTCTRoot.pem Baltimore Cyber Trust Root
GTECTGlobalRoot.pem GTE Cyber Trust Global Root
Pcs3ss_v4.pem Class 3 Public Primary Certification Authority
GeoTrust_Global_CA.pem GeoTrust

You are not required to obtain and install root certificates on the user device to use the certificates from these Certificate Authorities. However, if you choose to use a different Certificate Authority, you must obtain and install a root certificate from the Certificate Authority on each user device.

Important: Receiver does not support keys of more than 4096 bits. You must ensure that the Certificate Authority root and intermediate certificates, and your server certificates, are less than or equal to 4096 bits long.
Note: Receiver for Linux 13.0 uses c_rehash from the local device. Version 13.1 and subsequent versions use the ctx_rehash tool as described in the following steps.

Use a root certificate

If you need to authenticate a server certificate that was issued by a certificate authority and is not yet trusted by the user device, follow these instructions before adding a StoreFront store.

  1. Obtain the root certificate in PEM format.
    Tip: If you cannot find a certificate in this format, use the openssl utility to convert a certificate in CRT format to a .pem file.
  2. As the user who installed the package (usually root):
    1. Copy the file to $ICAROOT/keystore/cacerts.
    2. Run the following command:

Use an intermediate certificate

If your StoreFront server is not able to provide the intermediate certificates that match the certificate it is using, or you need to install intermediate certificates to support smart card users, follow these steps before adding a StoreFront store.

  1. Obtain the intermediate certificate(s) separately in PEM format.
    Tip: If you cannot find a certificate in this format, use the openssl utility to convert a certificate in CRT format to a .pem file.
  2. As the user who installed the package (usually root):
    1. Copy the file(s) to $ICAROOT/keystore/intcerts.
    2. Run the following command as the user who installed the package:

Enabling smart card support

Receiver for Linux provides support for a number of smart card readers. If smart card support is enabled for both the server and Receiver, you can use smart cards for the following purposes:

  • Smart card logon authentication. Use smart cards to authenticate users to Citrix XenApp servers.
  • Smart card application support. Enable smart card-aware published applications to access local smart card devices.

Smart card data is security sensitive and should be transmitted over a secure authenticated channel, such as TLS.

Smart card support has the following prerequisites:

  • Your smart card readers and published applications must be PC/SC industry standard compliant.
  • You must install the appropriate driver for your smart card.
  • You must install the PC/SC Lite package.
  • You must install and run the pcscd Daemon, which provides middleware to access the smart card using PC/SC.
  • On a 64-bit system, both 64-bit and 32-bit versions of the "libpscslite1" package must be present.
Important: If you are using the SunRay terminal with SunRay server software Version 2.0 or later, you must install the PC/SC SRCOM bypass package, available for download from

For more information about configuring smart card support on your servers, see the XenDesktop and XenApp documentation.

Connecting through NetScaler Gateway

Citrix NetScaler Gateway (formerly Access Gateway) secures connections to StoreFront stores, and lets administrators control, in a detailed way, user access to desktops and applications.

To connect to desktops and applications through NetScaler Gateway

  1. Specify the NetScaler Gateway URL that your administrator provides. You can do this in one of these ways:
    • The first time you use the self-service user interface, you are prompted to enter the URL in the Add Account dialog box
    • When you later use the self-service user interface, enter the URL by clicking Preferences > Accounts > Add
    • If you are establishing a connection with the storebrowse command, enter the URL at the command line

    The URL specifies the gateway and, optionally, a specific store:

    • To connect to the first store that Receiver finds, use a URL of the form
    • To connect to a specific store, use a URL of the form<storename>. Note that this dynamic URL is in a non-standard form; do not include = (the equals sign character) in the URL. If you are establishing a connection to a specific store with storebrowse, you will likely need quotation marks around the URL in the storebrowse command.
  2. When prompted, connect to the store (through the gateway) using your user name, password, and security token. For more information on this step, see the NetScaler Gateway documentation.

    When authentication is complete, your desktops and applications are displayed.