When Receiver for HTML5 is hosted on a https site (default and recommended), non SSL/TLS websocket connections are prohibited by browsers.
In explaining the technical reason behind this it is important to understand the following two principles:
1. As opposed to existing as a separate process, Citrix Receiver for HTML5 operates within the frame and process space of the browser itself. As such the browser has the ability to enforce certain security parameters.
2. Additionally, when any Receiver (or Workspace App for newer versions) makes a connection to a VDA for either a published desktop or app, the underlying connection is made to the VDA and not the Storefront server as any kind of intermediate proxy.
This second point is less obvious in the case of Citrix Receiver for HTML5 because the published desktop or app displays within the browser frame and “appears” to be connected via the Storefront server. Despite this appearance though, the underlying TCP/UDP connection is still between the client and the VDA. If the Storefront base URL is SSL enabled (where it begins with https as is best practice) and the VDA is not SSL enabled (which it is not by default) the browser in this case will prevent the connection due to what it sees as an underlying inconsistency. The inconsistency is that while the URL shown in the browser frame is prefixed with https, the actual underlying connection is not https even though it is not obvious to the user.
There are two solutions for this.
Solution 1 is to enable SSL on the VDA using one of these guides:
This will ensure that the connection path is SSL enabled between the internal client and the VDA.
Solution 2 is to have your connections from the clients first go through a Netscaler Gateway. Netscaler Gateway will proxy the connections and perform a SSL handshake between the client and the Netscaler. In this scenario there is no inconsistency and connections via HTML5 Receiver will succeed.