How to configure StoreFront 2.x with SSL certificates to encrypt XenDesktop 7 traffic – Detailed step by step

How to configure StoreFront (2.x) with SSL Certificates when using a Load Balancer – In Detail


An important part of a large XenDesktop 7.x implementation is delivering the apps to the clients.

No matter if you are configuring StoreFront 2.0, 2.1 or 2.5 (or later), installing the SSL certificartes is an important step when building the infrastructure.

In this article we will show how to configure multiple StoreFront 2.x servers with SSL certificates using a DNS alias that will be used with a Load balancing solution. This way we can activate the HTTPS encryption for the traffic between the Citrix Receiver and StoreFront, and StoreFront and the Delivery Controller(s). If you don’t work with SSL, all traffic will be XML, which I’m sure you don’t really want in a large enterprise.’

Overview of steps to be taken

1.1 Create a DNS alias entry CNAME.. 3
1.2 Part 1 Certificate Request (via IIS console): Create a SSL certificate for the Storefront server. 3
1.3 Part 2: Creating/downloading the certificate: Download the certificate from your MS Certificate Authority server
1.4 Part 3: Configure SSL: Install the Certificate in the local server’s certificate store. 10
1.5 Part 4: Configure SSL: Configure the StoreFront website to use SSL. 11
1.6 Test the implementation. 14
1.7 Extra configuration for a Load balanced Storefront 15



Request a certificate


Click on advanced certificate request


Select Submit a certificate request by using a base-64-encoded CMC….


Copy all the contents of the c:\certificate_request_SF1.txt (including —START — and —END—) into the first field.

Select Web Server

Click Submit


Select Base 64 encoded

and click Download certificate

to download the certificate file.


The result is this file certnew.crt.

Since this is the final certificate, I prefer to save it as FQDN – STOREFRONT.DOMAIN.COM to its clear for which server it is, and that is used with a Load balanced DNS address-

and check if you get the welcome to IIS message and no certificate error.

Note the SSL encryption will ONLY work when using the EXACT FQDN

Connecting to

Will not work.
Internet Explorer will tell you the Certificate is NOT Correct.

Citrix Receiver will not show you application icons, the Storefront web interface will not show you icons, communication between StoreFront and Delivery Controller will be denied!
All Configuration MUST be done with


Browse to the StoreFront Citrix URL (called “Receiver for Web” in Citrix Studio, very confusing)
Log in, and test the applications.

Configure Citrix Receiver to use the following address:
Log in, and test the applications.

1.7 Extra configuration for a Load balanced Storefront


In order to make sure the Storefront server can successfully communicate with themselves, create an entry in the hosts file that point to the own server IP, not the VIP one.

This is important when synscronising changes between the StoreFront servers.


Note: Every StoreFront server will have a different IP in the host file.


Repeat the same actions for all StoreFront servers you have.




1. Private key is missing.

You or someone who provided the certificate to you created one with a Public Key, but the Private Key is missing.
It needs the private key for authentication.


Open MMC > certificates > Local Computer > personal store:
You can already determine if the certificate has a private key, when looking at the icon:
-> the second one has a private key
If you open the certificate, it is also displayed in the first window:

2. The wrong template was used.

You or someone who provided the certificate to you used a wrong template to create the certificate.
For example a Workstation template was chosen.


It should be webserver template

Webserver ISA template also should to work (contains more options, however not correct for this purpose). It has more purposes:

  • IP security IKE intermediate
  • Client Authentication
  • Server Authentication

Important that is has these properties:

What also could be wrong is the encryption strength, although that would not prevent the certificate from displaying in IIS bindings.

Generally 2048 bits is used nowadays.