HowTo: Enable SSL and Secure XML Traffic on Citrix Delivery Controllers – Easy Method

One of the cardinal sins of anyone implementing a Citrix virtualization platform is not enabling SSL\TLS and securing XML traffic 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:

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 in context of Citrix, 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

I’d love Citrix to make this easier to do and build in a feature to facilitate this which may increase adoption of this security measure. 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 the 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 Controller 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.

Update November 5th 2019: A commenter has astutely indicated that this process uses the Product ID vs. the App ID. However, it would appear the Product ID still allows the certificate to work with the Citrix Broker Service as evidenced by XML services being successfully secured. We are not aware of any issues with this process as described and it continues to work on LTSR and CR versions from both our testing and that of the Citrix community.