HowTo: Enable SSL on Citrix Delivery Controllers – Easy Method

December 19th, 2018

One of the cardinal sins of anyone implementing a Citrix virtualization platform is not securing XML and STA services on the Delivery Controllers (aka brokers). Although passwords are hashed in transit over HTTP, the encoding is very weak and easily decrypted through basic tools. Beyond that, user names, app entitlements, and group memberships can all go cleartext if left to the default HTTP\TCP 80 configuration.

I won’t mince words, not securing XML is lazy and irresponsible in this day and age. I come down hard on customers who do not secure their XML traffic and sadly 7/10 times I’d wager it’s logged as a high-risk item on our infrastructure assessments.

If you’re interested in the rationale of this stance, I’d recommend reading this excellent blog Securing the XenApp/XenDesktop XML Service – Important Steps to Prevent Theft of User Passwords that gives a good deep-dive into the architecture and traffic flows of XML along with which scenarios put environments at risk (namely explicit authentication).

In the partial defense of the consultants and admins who have left this unsecured but at least investigated it, Citrix’s documentation hasn’t exactly been great, and the instructions have been tedious.

These days when searching enabling SSL on controllers, you often come up with this KB which is quite underwhelming:

https://support.citrix.com/article/CTX200415

Which then links over to this collection of Microsoft links, effectively passing the buck on instruction to Microsoft, at which point without clear direction and steps, many may forego the process:

https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/secure/tls.html

There is a much older Citrix KB which details the process steps (albeit very manual and lengthy) and although it lists it as being for XenDesktop 5.x, it works with all current versions of the FMA architecture (IMA used SSL Relay for this):

https://support.citrix.com/article/CTX130213

Strange that one doesn’t come up more often than the first.

Ideally, I’d love Citrix to make this easier to do and build in a feature to facilitate this. In the meantime, here’s some steps to get through the process in a shorter timeframe. This blog assumes:

  • You do not have IIS installed on the Delivery Controllers (i.e. not collocated with StoreFront or Director) which would be the recommended practices for enterprise deployments, where one doesn’t collocate different roles on the same server, to minimize attack surface among other virtues.
  • Delivery Controller software is installed.
  • You already have a certificate installed with private key on your controllers and the FQDN of the server is listed in the certificate.

Step 1 – Grab your certificate thumbprint.

Load up MMC snap-in, and add Certificates (computer), locate the personal store certificate to be used, and check its thumbprint in its properties. Note that it has a space every couple characters which is a problem for us. If only one cert is on the server, move to the next step. Otherwise, note the first few characters of the thumbprint to locate the proper cert in the step.

Load up PowerShell as an admin and run these commands:
Set-Location Cert:\LocalMachine\My
Get-ChildItem | Format-Table Subject, FriendlyName, Thumbprint -AutoSize

This will pump out the certs and the thumbprints without the spaces, making for easy copying of the thumbprint. Now you have data point 1 (certhash).

Step 2 – Locate the App ID of the Citrix Broker Service

The old Citrix document would have you wade through the registry finding this, and then have you add in dashes at random.  Easier method while still in PowerShell is to run this:
Get-WmiObject -Class Win32_Product | Select-String -Pattern "broker"

This will pump out a few values. We care about the “Citrix Broker Service” line, and as you’ll see already has the dashes injected for us, as Windows wants for the next step. Now you have data point 2 (appid).

Step 3 – Bind the certificate to the Citrix Broker Service via it’s App ID

Now we use Windows’ netsh command to bind the cert to the Citrix service. Note this can’t be done via PoSH as you’ll see below, so just type cmd to get back down to a standard prompt and use the following syntax:
netsh http add sslcert ipport=0.0.0.0:443 certhash=<hash number> appid={Citrix Broker Service GUID}

Done! Should have this down to less than 5 minutes per server with these steps.

Next Steps:

  • Be sure to track your certificate expiry to avoid failure of XML and STA capabilities.
  • Replace STAs on your Citrix Gateway vServers with https equivalents. Ensure firewall rules are open first.
  • Update your StoreFront’s NetScaler Gateway objects to use the updated STAs, to match what was updated on the Citrix Gateways
  • Reconfigure your StoreFront Controllers configurations to use HTTPS, if a VIP is used to load balance XML (strong recommendation) ensure it’s been re-created to use HTTPS vs HTTP.

3
Leave a Reply

avatar
2 Comment threads
1 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
Michael ShusterCarl WebsterJosef Malmborg Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Josef Malmborg
Guest
Josef Malmborg

Excellent article, yes, we should use or as you say: Citrix should change the installation or GUI so its easier to select HTTPS for connections.

Carl Webster
Guest

Excellent article. I would change this:

Select-String -Pattern “broker”

To

Select-String -Pattern “citrix broker service”

to get just one item returned.

I am working on a script to automate this process. You will get credit for giving me the idea.