Securing XML Traffic Between Delivery Controller/Cloud Connectors and StoreFront

by Ray Davis, CTA, Jacksonville CUGC Leader

Most of everyone that does Citrix understands that security of the XML traffic between Delivery Controllers/Citrix Cloud Connectors and StoreFront typically is a must. There may be some situations where some folks may not need it, but that is rare. Things like:

  • It’s only used internally and has no gateway.
  • Gateway is used, but again it’s all internally.
  • VPN is used from laptop setup, and they hit the internal Citrix Environment.
  • The organization is new to Citrix and may not understand all the moving parts. To them, things work, and it may be out of sight, and out of mind.

I am sure there are many other cases. But I ran into a few in the last year or so. I also secure it in the bullets I listed above to cover any bases. I found out that in some cases, the company security team will scan the environment with their tools, and it will show up in a report, which will cause you to secure it anyway. My thoughts are to do it in the beginning, and it is completed. Some may disagree, but that is ok 😊. When doing Citrix deployments for clients, I always try to follow Citrix Security best practices. I will list a comprehensive list of what I follow that I put together through the years at the end of the blog.

Long way

I would say most of you understand this way, and this is not anything new. However, I will review it anyway and give you a working example, just in case. Many blogs will cover this same concept online. It’s a typical case, and many folks have written it up. This is assuming you don’t have your Director Servers in the DDC as well. I have seen some occasions where this was the case. Some folks say that is bad, and others say it’s ok. In my opinion, it all depends on the environment’s size and resources. I would preach to separate them from my perspective around security considerations, no need to put IIS on a delivery controller IMHO. Enroll for a Computer Cert, but at the time, this is what I had. So, I request a Cert in my case.

Secure XML Traffic
Secure XML Traffic
Secure XML Traffic

Note: WebServer does not have to be selected. At the time, It was what I used.

Secure XML Traffic
Secure XML Traffic
Secure XML Traffic

Pick the CA based on the location that will match your environment.

Secure XML Traffic
Secure XML Traffic
Secure XML Traffic
Secure XML Traffic
  1. Open PowerShell and run this 
  2. Grab the Thumprint 
  3. Set-Location Cert:\LocalMachine\My 
  4. Get-ChildItem | Format-Table Subject, FriendlyName, Thumbprint -AutoSize 
Secure XML Traffic
  1. You can also get it a bit cleaner with this. (Either way works)
    1. Get-ChildItem -Path Cert:\LocalMachine\my | Select-Object FriendlyName, Thumbprint, Subject, NotBefore, NotAfter
Secure XML Traffic
  1. Locate the App ID of the Citrix Broker Services (Cloud Connector). You can do it with “broker” or “Citrix broker Service” it depends on if you are using the command for the older CVAD version vs CR version. However, this is a cloud connector either one works—just extra information.
  2. Get-WmiObject -Class Win32_Product | Select-String -Pattern “broker.” 
  3. Get-WmiObject -Class Win32_Product | Select-String -Pattern “citrix broker service.”
Secure XML Traffic
  1. Within PowerShell, do this:
    • netsh http>
    • If you have an existing cert, run this to remove it:
      • delete sslcert ipport= (use option C if you don’t want to do this) 
  2. Otherwise:
    • add sslcert ipport= certhash=17BE86B8271FF234662D47DBAC61D688D4A6C0FA appid= {ff8980ed-53ce-dcf4-3879-4ee77227aaab}
  3. If you get an error and don’t want to delete the old one, use this instead. 
    • Update sslcert ipport= certhash=17BE86B8271FF234662D47DBAC61D688D4A6C0FA appid={ff8980ed-53ce-dcf4-3879-4ee77227aaab}
  4. Show sllcert
Secure XML Traffic

add sslcert ipport= certhash= BCD7BF8EA1C491E7D4FFF3086975B10A67CDA4E7 appid= {DE0898FF-EC35-4FCD-8397-E47E2772AABA}

Secure XML Traffic

In the Registry, you will see two keys in this location. If you want to ignore the HTTP traffic, Create a DWORD with the name XMLServicesEnableNonSSL and value 0x0


  • XmlServicePort = 80
  • XmlServicesSslPort = 443
  • Add XMLServicesEnableNonSSL and value 0x0

Short way and much more manageable.

I had a couple of questions and reached out to the World of EUC on things. James Kindon sent me a Github script that does all this in one shot. I was amazed, and I chose to do this to show you the ease of automation.

  • Pull down the script, and put it in a location on the DDC/CC. There are many parameters with different options. The one I needed was this. .\EnableSSL_XML.ps1 -EnableSSL -DisableHTTP
    • Line 29 – PS C:\> .\EnableSSL.ps1 -EnableSSL -DisableHTTP
    • The above example will prompt for a certificate and, once selected, will create the appropriate SSL binding. It will also disable answering XML requests on HTTP
    • Assing the DDC/CC a machine cert and follow this.
    • Note: I did this on an on-prem Delivery Controller this time around. The same applies to the Cloud Connector, though.
Secure XML Traffic
Secure XML Traffic
Secure XML Traffic

Then you can run “.\EnableSSL_XML.ps1 -ValidateSSLStatus” to check the status.

Secure XML Traffic
Secure XML Traffic

That’s all! 😊

I use this method for all my clients now, it quick and does the job very well.

I want to test it over port 80 and get some essential network traffic findings. I would like to see the outcome and show you as well.

Secure XML Traffic

What I expect to happen is when I launch a Desktop/App, the StoreFront server will contact the DDC in this example over port 80, as I specified above, to show you that the script disabled it from working even though I said in the SF console to use it. It should error out and offer something in the logs.

Secure XML Traffic

This is a packet capture. You can see SF tried to reach out over port 80

Secure XML Traffic

Then I received this nice but nasty error.

Secure XML Traffic
Secure XML Traffic
Secure XML Traffic

Ok, so we knew that would happen. Now I will put it back to 443.

Secure XML Traffic
Secure XML Traffic


How to Enable SSL on Cloud Connectors to Secure XML Traffic (

Citrix Cloud – Enabling SSL on Cloud Connector to secure XML/STA Traffic. – David Wilkinson

This is what I always followed as I applied it to the cloud connectors as well.

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

Biggest reference was this (One stop show- that does it all) Citrix/EnableSSL.ps1 at master · JamesKindon/Citrix · GitHub

As promised, here are the security checks that I follow, the list grows as I discover new things.

High level of security checks

User Layer

  1. Device Lockdown
  2. GPO hardening- Security baselines guide | Microsoft Learn
  3. Auditing for event logs –
    1.  Security auditing (Windows 10) | Microsoft Learn
    1. Recommended advanced audit logging – Truesec
  4. Endpoint logging with a SIEM
  5. Proper path cycle (Patch Tuesday goes to test/dev, next week is prod-unless it’s a Zero day)
    1. Windows Server Patching: Best Practices – TechNet Articles – United States (English) – TechNet Wiki (
  6. Citrix Workspace App Security
    1. Secure communications | Citrix Workspace app for Windows
    1. Security update SSON CWA
  7. Windows TLS Ciphers-
    1. Cipher Suites in TLS/SSL (Schannel SSP) – Win32 apps | Microsoft Learn
  8. CWA App protection (Workspace side)
  9. CWA Secure ICA File session launch
    • Enabled “Secure ICA File Session launch” This will block the ICA files from being opened by browsers that can’t use the ICA in memory
      • ICA File Settings > RemoveICAFile (remove ICA files, if downloaded)
  10. CWA TLS Support

Access layer

  1. NetScaler Gateway URL scans
  1. Strong Authentication
    • MFA\2factor
    • LDAPS only – not ldap by all means
  1. Encryption- XLM Traffic

3a. Cloud Connector ( Windows)

4. Store Front SSL

5. VDA/HDX Encryption
SSL configuration on VDA (

Resource layer

  1. Harding Windows Images
Secure XML Traffic
Secure XML Traffic
Secure XML Traffic
Secure XML Traffic
Secure XML Traffic
Secure XML Traffic
  1. Hide Admin shares
    • On Windows systems, there are typically “admin” shares called c$ (for example) for admins to connect to the c: drive remotely. However, these shares are now by default open to all interactive users, which includes users logged on to Citrix Virtual Apps systems. This means a user can access the local drive by browsing to \\LOCALHOST\C$ or the network loopback address of \\\C$
    • In order to prevent this, it is recommended to set a Registry value via GPO or in the image so that the behavior reverts to that used previously. The Registry value is a hexadecimal entry so should be imported from a .reg file rather than entered by hand
    • Once this is in place, users will no longer be able to connect to these hidden shares and gain entry to local drives. It will also block these connections from Chrome, Internet Explorer, Microsoft Edge or Edge Chromium
    • Administrators can still connect to these shares remotely, which was the original purpose of these hidden shares
    • Admin shares available to non-administrative users over loopback address (
Secure XML Traffic


  1. Set WinRM HTTPS(if used)
  2. Set Auditing policy Best practice on VDA
  3. Locked down TLS and Windows TLS Ciphers
  4. Pathing and updates
    • Test/Dev/QA/Prod approach
  5. Antivirus Software

Common Criteria Certification Information – Citrix
Securing Citrix Virtual Apps and Desktops Environments – Citrix
System Hardening Guidance for XenApp and XenDesktop (
VDA Hardening – Tech Paper: Citrix VDA Operating System Hardening Guide

  1. Citrix Lock down policies
  2. Citrix Session Recordions
  1. Watermarking
    For sessions that have a user accessing sensitive data, a great deterrent to having the data be stolen is a watermark. Especially if the watermark can uniquely identify the user. Citrix enables admins to configure what to display. You can display:
  2. VDA Security Hardening CitrixTech Zone

Control Layer

  1. Ensure Availability

When deploying any solution, components must be deployed in a highly available manner. Having services that are suffering constant outages due to single points of failure is poor practice. Therefore, using the N+1 approach to capacity ensures that there is enough resource available during logon and log off storms. But there is an acceptable level of component loss to retain the ‘good’ user experience. Now, most customers follow N+1 in terms of planning the amount of resources that need to be available. However, depending on the tolerable level of risk, this may be N+2.

Also, to ensure there are enough resources available to handle the user load, components should be separated off onto dedicated virtual machines. It is bad practice to run shared components on virtual machines, not only from a performance perspective, but also security. Key components from a Citrix perspective are as follows, but not limited to:

  • StoreFront
  • Delivery Controllers
  • SQL Server
  • Federated Authentication Service
  • Director
  • License Server
  • Cloud Connectors
  1. Citrix Printing security
  2. Citrix FAS security
Secure XML Traffic
  • List only SF servers
  • If possible, list on the VDAs (create groups if needed)
  • If Possible, list users that use the SF servers
  • Change the Cryptogrpahy Key Size from 1024 to 2048 Bit
Secure XML Traffic
  • Modify the Extended Key Usage (EKU) from “All” to “Smart Card Logon” only
Secure XML Traffic
  • DCOM Firewall
Secure XML Traffic

Host Layer

  1. Hardware Separation
    • Separate workloads into unique clusters and ensure that workloads hosting the same data classification are retained within those unique clusters. If an attacker broke into the hypervisor layer somehow, higher classifications of data are not compromised.
  2. Network Separation
    Breaking down workloads into individual subnets that are logically separated, can dramatically reduce the impact, or spread of an attack. Usually, these subnet layouts are a perfect place to start:
    • Access Components. Small subnet compromising of the ADC IP addresses and call-back gateway.
    • Citrix Infrastructure. The Citrix infrastructure subnet depending on the infrastructure being deployed would include the following; StoreFront, Cloud Connectors/Controllers, Director servers, Citrix ADM.
    • Supporting Infrastructure. Depending on which infrastructure components are required, these services are prime examples for separation; SQL servers, Jump servers, and Licensing servers. This is dependent on your compliance needs.
    • VDA Subnets. There is no right or wrong answer when sizing the VDA subnets. In the past, we have used historical data to guide us around PVS subnet sizing. Over time, PVS recommended practices have evolved. The main thing to note is that subnet sizing must be allocated based on the number of users and VDAs and the security context that they are accessing. Placing users with a similar risk profile into a single subnet can also ensure that each of these subnets can be separated by a firewall.
  3. Firewalls
    Firewalls are one of the primary elements of implementing security in an environment. Implementing host-based and network-based firewalls will introduce significant operational overhead. Implementing two levels of firewalls from both a host-based and network-level will allow for separation of duties. This step allows an application to communicate from one server to another. Any firewall rules must be well documented and clearly marked as to which roles or functions are assigned. This detail will assist you in getting approvals for exceptions from your security and network teams.

Secure Citrix Cloud platform
Secure Deployment Guide for the Citrix Cloud Platform

Citrix DaaS Technical Security Overview
Technical security overview | Citrix DaaS          
Delegated administration | Citrix DaaS

Citrix Site Analytics Delegated Admins

Citrix DaaS Reference Architecture
Reference Architecture: Citrix DaaS | Citrix Tech Zone

Leave a Reply