#Citrix #POC #XenDesktop #vCenter #VMware #ESX
This article examines the use of VMWare ESX Hypervisor to host Citrix XenDesktop. In this section, I discuss the most common issues associated with the vCenter self-signed certificate used to configure a XenDesktop site.
A previous article, "Citrix XenDesktop 7.6 Core Software Install
" provides assumptions for the proof-of-concept by installing the XenDesktop core install on a single server using SQL Express on VMware ESX hypervisor.
Citrix XenDesktop requires vSphere server installed on a Microsoft Server to facilitate hypervisor communication where using VMWare ESX(i). Citrix supports;
- VMWare ESX
- Microsoft Hyper-V
- XenServer open-source (xen.org)
A virtual desktop infrastructure (VDI) proof-of-concept (POC) is possible when the prerequisites such as Citrix XenApp, StoreFront, and Netscaler exist. Citrix XenApp is a conduit for the business application where Citrix XenDesktop is a conduit for accessing the business application hosted on XenApp. Citrix Storefront is the latest self-service technology from Citrix and it requires Citrix Netscaler for full functionality.
Before running XenDesktop Studio,
there are a few common defects preventable by making a few simple changes to vSphere Windows server. The assumption is that one vSphere server exists with storage attached.
A potential defect is not being able to use HTTPS
to the SDK,
which XenDesktop configuration requires in version 7.6. Rather than wait for that error message I use the term "defect prevention
" to prevent these common mistakes from happening.
- Name mismatch
- Microsoft Certificate Trust Lists
During the XenDesktop install it will ask for the VMware SDK URL
and by default, the Microsoft vSphere service uses a self-signed certificate. This is probably okay for proof-of-concept (POC).
A self-signed certificate means the private key and certificate request get presented to the local system for signing and the local server is the certificate authority (CA). By default, the Windows operating system local Crypto store containing the "certificate trust lists
" (CTL) does not recognize self-signed TLS certificates.
According to Microsoft
For Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista, apply the appropriate update listed in document 2677070 in the Microsoft Knowledge Base.
For Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, or Windows Vista, apply the appropriate update listed in document 2813430 in the Microsoft Knowledge Base.
Any TLS certificate not having the certificate chain of trust or certificate authority (CA) listed in the CTL
is unrecognized. If the Certificate name matches the DNS A-Record you can bypass the name mismatch error. The certificate authority (CA) is the hostname of the computer that generates the certificate request, private key, and then the certificate file.
"A certification authority (CA) is responsible for attesting to the identity of users, computers, and organizations. The CA authenticates an entity and vouches for that identity by issuing a digitally signed certificate. The CA can also manage, revoke, and renew certificates." REFERENCE: Certification Authority Guidance]
In some environments, a self-signed certificate might show up on a security scan report. In this scenario, I have indicated an isolated lab environment behind a firewall. Otherwise, I recommend using a third-party certificate and hardening the operating system per my article: Citrix SSL/TLS Vulnerabilities and Operating System Hardening
The default installation generates a self-signed certificate. The certificate is located on the vSphere server and bound to several Windows services. The location of these SSL files or RUI.PFX file differs from the version of the VMWare software. The location for vSphere 5.5, default, is C:\ProgramData\VMWare\vSphere Web Client\ssl.
file contains the CRT (.crt) (certificate) Note
: This is the same as the CER (.cer) extension] and private key file. This is not the only way to obtain the certificate but is recommended when using the default self-signed certificate, as opposed to using a third-party certificate where the vendor is listed in the CTL.
certificate (Transport Layer Security
) directory contains the private key (.KEY
) and certificate file (.CRT
). In some scenarios where firewall rules exists the CRT file is not enough. The Microsoft Crypto library and custom MMC are not designed to import just a private key (.KEY
); they will import a PFX
file which is the private key (.KEY
) and certificate file (.CRT or .CER
). The RUI.PFX has a default password required to import the file.
Before importing the self-signed certificate and private key perform validation on the "rui.crt"
for the "Issued by"
and "Valid from"
The default installation without modification of the "proxy.xml
" file is the SERVERNAME (short-name). In this scenario, the DNS zone matches Active Directory Domain name. The certificate displays the short name value of "VCENTERPOC01
Check the Subject Alternative Names
name as well. The SAN
typically uses the FQDN of the SERVERNAME.addomain.com. This might suffice if the AD Domain is same as DNS Domain name. Often the DNS Zone or domain for registered certificates differs from the Active Directory Domain.
Double-click the certificate, and click the "Details
" tab. Check the "Signature algorithm
" first because this can cause a security finding if SHA2
. This one is SHA256 RSA
, which should be okay. If the Signature algorithm is SHA2
or hash is 128
please review SSL/TLS Vulnerabilities and Operating System Hardening.
In this scenario, the lab is behind a firewall so only certain ports are allowed. Even if we address the "Certificate Name Mismatch"
errors there are additional preventable errors. These errors give the impression of something being wrong with the RUI.pfx file or that something was done wrong in previous steps. Importing the PFX file adds the certificate and private key to the local Crypto store but vSphere has services bound to ports other than TCP 80 and 443.
Every release of Citrix requires encryption to work. By default, the SDK "proxy.xml"
file is not set to redirect HTTPS, only to HTTP
. Changes must be made to "proxy.xml"
on vCenter to prevent failures as follows;
Using the latest version of Notepad++
add the latest XML tools
using Plugin Manager
. This provides a better view of syntax than standard notepad.
Log in to the vCenter server as a local Administrator (NTFS permissions to modify files, stop and start services).
Connect to the administrative share from a workstation with Notepad++ (or some other text editor) installed.
file is located at C:\ProgramData\VMWare\VMware VirtualCenter
or "\\VCENTERPOC01\C$\ProgramData\VMware\VMware VirtualCenter"
The first change located under "vim.Proxyservice.LocalTunnelSpec
" and where "<accessMode
>" equals "httpOnly
Although XenDesktop does not use this service or port it does use others and best practice is to be consistent. For SDKTunnel, modify "httpOnly
" to "httpHttps
This next change is related to the SSO Console. Normally, typing https://vcenterpoc01:9443
would generate a certificate name mismatch. Using https://vcenterpoc01.vcissgroup.com
would generate an "Unrecognized..." error. To that Windows server vcissgroup.com is not approved. This requires manual intervention.
- Add DNS A-record for the name that matches the certificate
- Replace the IP Address in proxy.xml with FQDN
Now, the SDK section. Change the default <accessMode>httpOnly
Click on Start > Run > and type "services.msc
" > and restart the "VMware vSphere Web Client
On the server allocated for XenDesktop, the plan here is to import the SDK certificate before installation of Citrix XenDesktop.
The standard certificate MMC tool is at the local user context, not local computer. Hence, a custom MMC, and choose "Local Computer".
- Login to the XenDesktop server with local Administrator rights
- Click on Start > Run > Type MMC.exe > Enter
Choose Certificates > Add > Computer Account > Next
Local Computer > Finish
Now, local Trusted People
> and click on Registry
> right click Registry
> All Tasks > Import
" the RUI.PFX
file to the Computer Store.
This assumes the RUI.pfx
file has been copied to Documents. If vCenter is behind a firewall (for a proof-of-concept, it usually is) then the UNC path to a share might not work. This requires copying the file locally.
Click on Browse > above the Open button, click the pull-down and select "Personal Information Exchange"
Assuming the file has been copied locally, select RUI.pfx
file > Click Open > and click Next
In summary, this covers the core installation of XenDesktop and gives a sure way to resolve certificate errors using the RUI.PFX file obtained from the vCenter server by copying it to the XenDesktop server and importing it using a custom MMC.
We used the self-signed certificate from vCenter but advise against it for future pilot and production scenarios.
Having addressed common issues and discussed self-signed certificates with SDK is a segway to my next article "Citrix XenDestop Site Configuration."
Free Citrix Tools and Training
Maximize Citrix Concurrent Licensing To Reduce Cost – Session Timeouts - 3 Millon Dollar Cost Save
SSL/TLS Vulnerabilities and Operating System Hardening
Does this shared knowledge provide value? If this article has value, please click on "Good Article" button to your right
. Knowing this knowledge is valued by others is motivation to continue sharing. Your support is greatly appreciated.