Product Documentation

Securing Receiver communications

Sep 22, 2016

In this artcle:

To secure the communication between your server farm and Receiver, you can integrate your Receiver connections to the server farm with a range of security technologies, including:
  • Citrix NetScaler Gateway or Citrix Access Gateway. For information about configuring these with Citrix StoreFront, refer to the StoreFront documentation.
    Note: Citrix recomms using NetScaler Gateway to secure communications between StoreFront servers and users' devices.
  • A SOCKS proxy server or secure proxy server (also known as security proxy server, HTTPS 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. You can use Secure Gateway with the Web Interface to provide a single, secure, encrypted point of access through the Internet to servers on internal corporate networks.
  • SSL Relay solutions with Transport Layer Security (TLS) protocols
  • 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.

Certificates

Private (Self-signed) certificates

If a private certificate is installed on the remote gateway, the root certificate for the organization's certificate authority must be installed on the user device to successfully access Citrix resources using Receiver.

Note: If the remote gateway's certificate cannot be verified upon connection (because the root certificate is not included in the local keystore), an untrusted certificate warning appears. If a user chooses to continue through the warning, a list of applications is displayed; however, applications fail to launch.

Importing root certificates on Receiver for Mac devices

Obtain the certificate issuer's root certificate and email it to an account configured on your device. When clicking the attachment, you are asked to import the root certificate.

Wildcard certificates

Wildcard certificates are used in place of individual server certificates for any server within the same domain. Receiver for Mac supports wildcard certificates.

Intermediate certificates with Access Gateway or NetScaler Gateway

If your certificate chain includes an intermediate certificate, the intermediate certificate must be added to the Access Gateway or NetScaler Gateway server certificate. For information on this task, refer to the NetScaler Gateway documentation in Citrix Product Documentation.

Connecting with NetScaler Gateway or Access Gateway Enterprise Edition

To enable remote users to connect to your CloudGateway deployment through NetScaler Gateway or Access Gateway, you can configure these to work with StoreFront (both components of CloudGateway). The method for enabling access depends on the edition of CloudGateway in your deployment.

If you deploy CloudGateway Express in your network, allow connections from internal or remote users to StoreFront through NetScaler Gateway or Access Gateway by integrating NetScaler Gateway or Access Gateway with StoreFront. This deployment allows users to connect to StoreFront to access published applications from XenApp and virtual desktops from XenDesktop. Users connect through Citrix Receiver.

For information on configuring these connections with NetScaler Gateway, refer to the sectionConfiguring NetScaler Gateway Settings with the Remote Access Wizard in Citrix Product Documentation. For information on configuring these connections with Access Gateway, refer to the section Integrating Access Gateway with CloudGateway in Citrix Product Documentation.

To enable remote users to connect through Access Gateway to your Web Interface deployment, configure Access Gateway to work with Web Interface, as described in the section in Citrix Product Documentation called Configuring Access Gateway Enterprise Edition to Communicate with the Web Interface, and the topics in that section.

Connecting with the Secure Gateway

This topic applies only to deployments using the Web Interface.

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 Web Interface server to connect to servers running the Secure Gateway. For more 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 about Relay mode, 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, my_computer.my_company.com is a 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.

Connecting through a proxy server

Proxy servers are used to limit access to and from your network, and to handle connections between Receiver and servers. Receiver supports both SOCKS and secure proxy protocols.

When communicating with the XenApp or XenDesktop server, Receiver uses proxy server settings that are configured remotely on the Web Interface server. For information about configuring proxy server settings for Receiver, see the Web Interface documentation.

When communicating with the Web server, Receiver uses the proxy server settings that are configured for the default Web browser on the user device. You must configure the proxy server settings for the default Web browser on the user device accordingly.

Connecting with the Secure Sockets Layer (SSL) Relay

You can integrate Receiver with the Secure Sockets Layer (SSL) Relay service. Receiver X1 for Mac 12.0 supports TLS 1.0, 1.1 and 1.2

Transport Layer Security (TLS) 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 Federal Information Processing Standard (FIPS) 140. FIPS 140 is a standard for cryptography.

By default, Citrix SSL Relay uses TCP port 443 on the Citrix 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 TLS+HTTPS browsing, to the Citrix XML Service.

You can use Citrix SSL Relay to secure communications:
  • Between a TLS-enabled Receiver and a server.
  • With a server running the Web Interface, between the XenApp server and the Web server.

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

Configuring and enabling Receiver for TLS

There are two main steps involved in setting up TLS:
  1. Set up SSL Relay on your XenApp or XenDesktop server and your Web Interface server and obtain and install the necessary server certificate. For more information, see the XenApp and Web Interface documentation.
  2. Install the equivalent root certificate on the user device.

Installing root certificates on user devices

To use TLS to secure communications between TLS-enabled Receivers and the server farm, you need a root certificate on the user device that can verify the signature of the Certificate Authority on the server certificate.

Mac OS X comes with about 100 commercial root certificates already installed, but if you want to use another certificate, you can obtain one from the Certificate Authority and install it on each user device.

Depending on your organization’s policies and procedures, you may want to install the root certificate on each user device instead of directing users to install it. The easiest and safest way is to add root certificates to the Mac OS X keychain.

To add a root certificate to the keychain

  1. Double-click the file containing the certificate. This automatically starts the Keychain Access application.
  2. In the Add Certificates dialog box, choose one of the following from the Keychain pop-up menu:
    • login (The certificate applies only to the current user.)
    • System (The certificate applies to all users of a device.)
  3. Click OK.
  4. Type your password in the Authenticate dialog box and then click OK.

The root certificate is installed and can be used by SSL-enabled clients and by any other application using SSL.

Connecting through a firewall

Network firewalls can allow or block packets based on the destination address and port. If you are using a firewall in your deployment, Receiver must be able to communicate through the firewall with both the Web server and Citrix server. The firewall must permit HTTP traffic (often over the standard HTTP port 80 or 443 if a secure Web server is in use) for user device to Web server communication. For Receiver to Citrix server communication, the firewall must permit inbound ICA traffic on ports 1494 and 2598.

If the firewall is configured for Network Address Translation (NAT), you can use the Web Interface to define mappings from internal addresses to external addresses and ports. For example, if your XenApp or XenDesktop server is not configured with an alternate address, you can configure the Web Interface to provide an alternate address to Receiver. Receiver then connects to the server using the external address and port number. For more information, see the Web Interface documentation.