Secure ICA connection to VDA using SSL

One of the requirements of using Receiver for HTML5 internally with HTTPS StoreFront sites is to encrypt the ICA connection rather than using clear text. This is a requirement since all modern browsers do not support unencrypted Web Socket connections from an HTTPS site which Receiver for HTML5 uses.

When you make a connection to Receiver for HTML5 the ICA/CGP (Session Reliability) protocols are wrapped inside the HTML5 protocol. Browsers do not like the fact you’re making an HTTP Web Sockets connection from an HTTPS StoreFront site. For this reason, we further encapsulate the HTML5 protocol inside SSL/TLS 443. This method ensures that a TLS/SSL connection is made from the end-client Receiver to the VDA and it’s worth noting that this is FIPS 140-2 (Federal Information Processing Standard) compliant.

Note: You must be using XenApp/XenDesktop 7.6 or later.

You can connect to published resources using Receiver for HTML5 from NetScaler or internally using HTTP StoreFront servers however when you want to connect internally using an HTTPS StoreFront server extra configuration is required:

  1. Certificate installed on each VDA.
  2. SSL enabled on the VDA.
  3. HDX SSL connections enabled on the selected Delivery Group.
  4. DNS resolution enabled on the Citrix site.

For your VDA’s to obtain certificates, you’ll need something like Active Directory Certificate Services to automate the enrolment. For persistent machines, this works just fine. For non-persistent machines that reset after reboot, you’ll need to configure a way for the machines to request a new certificate after every reboot.

For those persistent machines, use Group Policy and navigate to Computer Configuration -> Policies -> Windows Settings -> Public Key Policies -> Automatic Certificate Request Settings -> New -> Automatic Certificate Request.

Click Next. Select the Computer template. Next. Finish. At this stage, computer certificates will enrol for every machine that receives this Group Policy. You should also configure the Group Policy setting Certificate Services Client – Auto-Enrollment to configure the renewal of expired certificates and removal of revoked certificates. When machines receive the new Group Policy and restart they will receive a computer certificate. Next copy the Enable-VdaSSL.ps1 script from your XenApp/XenDesktop media’s Support/Tools/SslSupport folder to a central location, accesibly by each VDA. On the VDA, run command Enable-VdaSSL.ps1 – Enable. Followed by A to set ACLs, configure the firewall rules (TCP 443) and enable SSL to VDA. This command disables the ICA (1494), Session Reliability (2598) and WebSocket (8008) firewall rules on the VDA so that TLS connections is only possibly. You should eventually get the message that SSL to VDA has been enabled.

Note: If you have more than one computer certificate on your VDA, you must specify the certificate you want to use for SSL using the certificates thumprint. The command would then be: Enable-VdaSSL.ps1 -Enable -CertificateThumbPrint “thumbprint”

Note: If you want to specify a port other than 443 for TLS, use command Enable-VdaSSL.ps1 -Enable -SSLPort 4443 for example.

Note: You can change the minimum SSL protocol used. By default TLS 1.0 is used. Run command Enable-VdaSSL -Enable -SSLMinVersion TLS_1.2 for example. Valid values are SSL_3.0, TLS_1.0, TLS_1.1, TLS_1.2

Note: You can disable VDA SSL by running command Enable-VdaSSL.ps1 -Disable. This deletes the SSL ICA rule, and re-enables CGP/ICA and WebSocket firewall rules.Now on your Delivery Controller, add the Citrix PowerShell snapins. Run the following commands:

  • Set-BrokerSite -DnsResolutionEnabled $true – This ensures the FQDN of the VDA is passed to the client within the ICA file. The FQDN matches the computer certificate so encryption can take place.
  • Get-BrokerAccessPolicyRue -DesktopGroupName “Delivery Group Name” | Set-BrokerAccessPolicyRule -HdxSslEnabled $true – This command enables SSL on the Delivery Group. You can’t enable SSL on individual machines.

On a side not if you are experiencing issues with connecting to resources using RfHTML5 you can enable logging by browsing to Now click Start Logging.

Note: Also check the VDA’s Event Log for events generated by the TcIca.Then log on to your Receiver for Web site, start a published application and a log file is generated. It can be downloaded to text file. This is a bad working log file, where the session was unexpectedly terminated before launch. And this is a good working log file where the session was successfully established. Finally after the certificate is enrolled and SSL enabled on the VDA/Delivery Controllers, I can make a successful direct connection.

The session is encrypted using TLS 1.2 and AES 256 bit encryption.


  • Travis

    November 12, 2017

    How does this work with a NetScaler? I’ve seen several guides but none discuss Secure ICA with a NetScaler.

    • George Spiers

      November 13, 2017

      If you have NetScaler in the mix, ICA traffic from an endpoint out on the internet to NetScaler is encryted by default. Then, ICA traffic from NetScaler to back-end VDAs is either unencrypted or encrypted depending on if you have implemented Secure ICA or not.

      • Travis

        November 13, 2017

        My question was meant more along the lines of “How does NS know that the VDA is using Secure ICA”. I assume it’s in the ICA file, but I can’t find any details on this or what I should look for in my ICA file to ensure it’s there.

        • George Spiers

          November 13, 2017

          Ah so yes, StoreFront ultimately produces the launch.ica file from information gathered from your Delivery Controllers. Such information contains the port on which HDX will connect on. From this NetScaler will know to establish 443 to the end-client but proxy ICA over port 1494 to the back-end for example.


Leave a Reply