Attempting to secure traffic between Citrix StoreFront server and the Delivery Controller with HTTPS fails causes login to display: “There are no apps or desktops available to you at this time.”

Problem

You’re attempting to secure the traffic between your Citrix XenDesktop or XenApp 7.5 / 7.6 environment so that your StoreFront server uses HTTPS instead of HTTP to communicate to Delivery Controller:

You’ve gone ahead and issued a certificate with a SAN entry of the Delivery Controller’s FQDN and binded it to the Delivery Controller’s IIS bindings:

You’ve also confirmed that you have updated your StoreFront’s URL to HTTPS instead of HTTP in Citrix Studio for your Delivery Controller configuration:

You’ve verified the port mappings by launching the command prompt, navigating to the directory:

C:\Program Files\Citrix\Broker\Service

… and executing:

brokerservice /show

SDK Port: 80
VDA Port: 80
WI Port: 80
WI SSL Port: 443
Log File:

With all the configuration and checks above completed, you proceed to restart your servers and test logging into via your NetScaler but quickly receive the following message upon successfully logging in:

There are no apps or desktops available to you at this time.

Reviewing the logs on the StoreFront Administrative Events shows 2 errors logged repeatedly:

Log Name: Citrix Delivery Services
Source: Citrix Store Service
Event ID: 4003
Level: Error
Message: All the Citrix XML Services configured for farm XenApp failed to respond to this XML Service transaction.

Log Name: Citrix Delivery Services
Source: Citrix Store Service
Event ID: 0
Level: Error
Message: An SSL connection could not be established: None of the SSL cipher suites offered TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_SHA, TLS_RSA_WITH_AES_256_SHA were accepted by the server.. This message was reported from the Citrix XML Service at address . The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services.

Note that Event ID 0 is logged first and Event ID 4003 is followed.

Solution

This issue threw me off quite a bit because my colleague had just gone through a XenDesktop 7.5 training course and when I review his lab guide demonstrating how to configure this, I was sure I haven’t missed any steps but while his lab environment was displaying applications after login, my environment did not.  I was pretty close to trying the solution Adam Paul Shattuck posted on a forum:

http://blog.technicall.us/xendesktop-7-x-how-to-deploy-in-a-highly-available-failover-ready-configuration-part-4-additional-delivery-controllers/

… where he did not have IIS installed on the Delivery Controller so used the netsh command to bind the SSH certificate to the Broker service with its GUID.  My environment had IIS so I decided to search for the Event ID 0 error since that was logged first and that was when I came across this blog post by Mark Brilman:

https://www.markbrilman.nl/2014/06/tutorial-implementing-a-secure-storefront-website-on-server-2012r2-behind-netscaler/

He had ran into an issue where his StoreFront server was logging the event ID 0 message:

An SSL connection could not be established: None of the SSL cipher suites offered TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_SHA, TLS_RSA_WITH_AES_256_SHA were accepted by the server.. This message was reported from the Citrix XML Service at address . The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services.

… and the way he fixed it was applying a GPO to his delivery controller enable a setting named SSL Cipher Suite Order.  The environment I was working on only had one delivery controller so instead of using a GPO, I launched gpedit.msc and enabled the setting as such:

Computer Configuration –> Administrative Templates –> Network –> SSL Configuration Settings

SSL Cipher Suite Order

I went ahead and enabled the configuration which automatically filled in the following for the SSL Cipher Suites textbox:

TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA

Clicking OK still showed the State as Not Configured:

… but checking the setting showed that it was enabled so I closed the box and ran gpupdate /force tested again but still got the same error.  Since Mark recommended to restart the server, I went ahead and restarted the server, tested again and noticed that the problem went away.  All applications were displayed properly and could be launched by clicking on them.