Jump to content
Welcome to our new Citrix community!
  • 0

Delivery Controller, VDA - SSL issues


Grant Lui

Question

Hi

 

We have attempted to setup SSL running on Citrix Components (Delivery Controller, Storefront and VDA) in an isolated environment. Each of the Components were installed in different VMs.

 

The following steps have been performed:

1. a commercial wildcard certificate was installed to each of the Delivery Controller, Storefront and VDA;

2. netsh command was executed on Delivery Controller to assign Broker service GUID to the related wildcard certificate;

3. registry was set on Delivery Controller to enforce HTTPS traffic (i.e. XmlServicesEnableNonSsl=0 AND XmlServicesEnableSsl=1);

4. Storefront was set to communicate with Delivery Controller using HTTPS and 443;

5. Enable-VdaSsl.ps1 script was executed on VDA with the related wildcard certificate thumbprint (only successful when VDA was given internet access); and

6. "Get-BrokerAccessPolicyRule -DesktopGroupName '<delivery-group-name>' | Set-BrokerAccessPolicyRule ‑HdxSslEnabled $true" AND "Set-BrokerSite –DnsResolutionEnabled $true" were also executed on the Delivery Controller.

 

Based on my understanding, the above steps are sufficient to setup everything to run SSL, I confirm the Delivery Controller is only accepting HTTPS communication from Storefront having to change the settings on Storefront to HTTPS and HTTP back and forth.

 

However, I noted the following:

1. it appears that the Delivery Controller is still communicating itself using HTTP (As seen in the below screenshot)

2. STA communication is still running under HTTP

3. we are still not able to connect to the VDA using the HTML5 Receiver from internal machines (As seen in the below screenshot)

 

As to point 3, log reports as follow:

SESSION:|:ICA:|:TRANSPORT:|:DRIVER:|:close with code=1006
CONNECTING :|: TRANSPORTDRIVER :|: CGP HANDSHAKE FAILED. TRYING ICA-Socks

 

Am I missing some steps here? Many thanks!

DDC.png

Error.png

Link to comment

8 answers to this question

Recommended Posts

  • 0

Hi Grant!

Were you able to fix the error? I currently have the same error with XenDesktop LTSR 7.15 CU3 and HTML5 session.

I've configured port 80 for the communication between DDC and SF. Is SSL communication over port 443 mandatory?

I'm using a Netscaler ADC gateway for the communication. It uses SSL/443.

The interesting fact is, that I can connect to XenApp via HTML5 without an error, only for XenDesktop it won't work.

Link to comment
  • 0
On 12/13/2018 at 8:10 AM, Björn Jeide said:

Hi Grant!

Were you able to fix the error? I currently have the same error with XenDesktop LTSR 7.15 CU3 and HTML5 session.

I've configured port 80 for the communication between DDC and SF. Is SSL communication over port 443 mandatory?

I'm using a Netscaler ADC gateway for the communication. It uses SSL/443.

The interesting fact is, that I can connect to XenApp via HTML5 without an error, only for XenDesktop it won't work.

 

Hi Bjoern

 

Sorry for this "rather late" response, for some reason I wans't notified on this thread.

 

Quote

However, I noted the following:

1. it appears that the Delivery Controller is still communicating itself using HTTP (As seen in the below screenshot)

2. STA communication is still running under HTTP

3. we are still not able to connect to the VDA using the HTML5 Receiver from internal machines (As seen in the below screenshot)

 

In terms of point no. 3, we still have not yet figured out the solution so we had set it aside. (We disabled the Enable-VdaSsl.ps1 script on the VDA and revert it to default setting).

 

In terms of point no. 2, the execution of the following commands to assign Broker service GUID on the DDC will enable STA communications over HTTPS, but sadly, HTTP is still listening.

 

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=<THUMBPRINT> appid={Broker Service GUID}

 

FYI, 443 communication is not mandatory for communications between DDC and SF, but it is highly recommended for nowadays end-to-end encryption environemnt (even for internal or DMZ traffics), you will particularly need to enforce TLS 1.2, decpreciate all TLS 1.1, 1.0 and SSL 3.0 Schannels and use stronger cipher suites.

 

You can do this either by editing the registry of the DDC and SF or using IISCrypto (quicker).

 

Screenshot1.thumb.png.b3c8fc9e404c87db5ce6a2098116c6fa.png

 

Infact, I have a feeling that your DDC and server VDAs might have implemented the said Schannels lockdown (i.e. accepting TLS 1.2 only), but your desktop VDAs are still trying to communicate using TLS 1.0 and thus the HTML5 connection doesn't work for your XenDesktop systems. However, this is purely my assumptions, but worth for you trying.

 

Hope these information helps.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...