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

citrix secure xml ssl traffic

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:

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:

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):

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).

citrix secure xml ssl traffic get certificate thumbprint

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).

citrix secure xml ssl traffic get broker service 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= certhash=<hash number> appid={Citrix Broker Service GUID}

citrix secure xml ssl traffic bind certificate to broker service

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.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Josef Malmborg
Josef Malmborg
2 years ago

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.

George Hamburger
George Hamburger
6 months ago
Reply to  Josef Malmborg

Couldn’t agree more. Product missing basic functionality.

Carl Webster
2 years ago

Excellent article. I would change this:

Select-String -Pattern “broker”


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.

Mark B
Mark B
2 years ago

Question about the Cert and the Trusted Root cert.
Most internet documentation says the end client needs the trusted root cert installed for this to work. But a home user with a personal device will never have the Corporate Trusted Root Cert (TRC). Will this work by just installing the TRC on the NetScaler? If not, does that mean I need a public cert (Go Daddy, etc) for my XML Servers?

Ron Krogel
Ron Krogel
2 years ago

I have seen where the “citrix broker service” exists but over time with updates the right key and different GUID might be required. 7.15 CU4 for example shows a different APP ID GUID and lists “Broker_Service_x64”

1 year ago

The method to get the App ID is INCORRECT.

Open Registry Editor and select Find.
Search for “Citrix Broker Service”.
The key (folder)’s name is the App ID.

DO NOT USE Get-WmiObject -Class Win32_Product | Select-String -Pattern “Citrix broker service” THAT IS THE PRODUCT ID, NOT THE APP ID.


1 year ago

The reason I mention this, Michael, is because the method I wrote is the same that you yourself linked to a (older) Citrix blog post. Carl Stallhood had this method on his site as well (which he got from Citrix back in the day): I can see he now uses your method 🙂 Could you explain the difference between yours and Citrix’s older method? Is there any difference? We would like to write it down in our documentation if for some reason yours is better. In order comments I have read that with updates, the string you get using… Read more »

1 year ago

Thank you very much for adding the comment at the end. Ive tried changing from the App ID to the Product ID (your method) and it SEEMS to be working correctly (quick test).

Edson Da Luz
Edson Da Luz
1 year ago

Hello Michael, this is a great and simple article, saved me a lot of trouble. Thank you. One note is that we can run netsh without switching to the Command Prompt. When copy-pasting the GUID, simply add quotes around the braces and the command will work. Cheers.

Howard Weise
Howard Weise
1 year ago

Excellent article from a top notch architect! Thanks Michael!

Igal Ezra
Igal Ezra
11 months ago

Tanks for the article.
Does this process equivalents to secure the STA to use https?

10 months ago

Even if the certificate expires, XML with SSL still work for STA, Storefront, no impact. It just needs to be done once time and that’s it. I’ve got this running in production and my certs are expires (7.15).

8 months ago

When I try to do it I obtain:
A specified logon session does not exist. It may already have been terminated.

Would love your thoughts, please comment.x