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:
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.
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.
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.
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:
For example: my_computer.my_company.com 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 (my_company.com) is generally referred to as the domain name.
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:
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.
You can control the versions of the TLS protocol that can be negotiated by adding the following configuration options in the [WFClient] section:
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.
|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|
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.
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.
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.
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 data is security sensitive and should be transmitted over a secure authenticated channel, such as TLS.
Smart card support has the following prerequisites:
For more information about configuring smart card support on your servers, see the XenDesktop and XenApp documentation.
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
The URL specifies the gateway and, optionally, a specific store:
When authentication is complete, your desktops and applications are displayed.