Import IIS SSL Certificate to Citrix NetScaler

5-18-2013 10-03-29 PMFor a recent project I’ve been configuring a Citrix NetScaler (which are wickedly cool) for load balancing of a web service over SSL. The web service is hosted on a Windows server using IIS, so I wanted to re-use the SSL certificate on the NetScaler. The steps to import IIS SSL certificate to NetScaler are actually fairly easy. I found various blog articles and Citrix KB articles on the process, but they were a bit convoluted and I thought there had to an easier process than using OpenSSL and WinSCP/NotePad to manipulate the certificate files.

The first thing you need to do is look in the server’s computer certificate personal store for your IIS certificate. In my case I’m looking for the certificate. Since I knew I’d be exporting the whole certificate (including the private key), I made sure when I was requesting the certificate to allow the private key to be exported. You can request certificates from your MS CA a variety of ways, so I’ll assume you can find the option to allow private key export.

5-18-2013 8-52-39 PM

Exporting the Certificate

1. Right click on the certificate select All Tasks then select Export. You should be presented with the option to export the private key. If not, then your certificate’s private key is “stuck” in the computer’s store and you can’t get it out. Issue a new certificate with the private key export option.

5-18-2013 8-58-01 PM

2. Assuming you can export the private key you are now given some options for the PKCS#12 certificate file. You shouldn’t need to select any of the options.

5-18-2013 8-59-29 PM

3. Select a strong password to protect the file with. Remember it.

4. Chose an appropriate filename for the certificate. I strongly suggest using the FQDN of the certificate, because the NetScaler will store the files with the name you choose. So don’t do something like “cert.pfx” since you will have no clue what site it is for. In my case I chose

5. Run through the same export wizard again, but this time select No, do not export the private key.

5-18-2013 9-04-19 PM

6. Select Base-64 encoding for your certificate.

5-18-2013 9-05-03 PM

7. Again, I suggest using the FQDN of the certificate for the filename (e.g. Make sure the file ends in “.cer”.

8. At this point you should have two certificate files, both with the FQDN, and one ending in .PFX and the other in .cer.

5-18-2013 9-06-50 PM

Importing Certificates into NetScaler

1. Logon to your Citrix NetScaler and open the root SSL page. Under Tools click Import PKCS#12.

import iis ssl netscaler

2. In the import window click on Browse next to the PKCS12 filename (NOT the output file name). Browse to your pfx file. Type in the password you entered during the certificate export process. Enter a new password to protect the private key on the Netscaler (PEM passphrase). In the Output File Name use the FQDN of the certificate and add a .key suffix. Change the encoding format to DES3. The NetScaler will automatically extract the private key from the PFX file and put it into the .key file.

5-18-2013 9-12-17 PM

3. Click on Manage Certificates / Keys / CSRs. Upload your .cer file. You should now see three certificate files with your certificate’s FQDN.

5-18-2013 9-17-12 PM

4. At this point you can delete the .pfx file if you wish, since we no longer need it. I suggest you do remove it, to reduce clutter on your NetScaler.

5. In the left pane under SSL click on Certificates then in the middle pane click on Install.

5-18-2013 9-18-41 PM

6. Enter the FQDN of your certificate in the Certificate-Key Pair Name. For the Certificate FIle Name select the .cer file you uploaded. For the Private Key File Name select your .key file. Enter the password you entered back in step 2.

5-18-2013 9-20-59 PM

7. If all goes well you will now have a new certificate from IIS installed on your NetScaler with no command line effort or manual modification of certificate files.

import iis ssl to netscaler

Citrix NetScaler Active Directory Authentication

The Citrix NetScaler can be configured to authenticate users against a variety of sources including RADIUS, LDAP, TACACS, and PKI certificates. If you are going to use the NetScaler as an Access Gateway (proxy) between and untrusted network such as the internet and your corporate network, you will probably want to have the NetScaler perform authentication functions.

Configuring the NetScaler for AD authentication is not difficult, but there are a few settings you should watch out for. I was using NetScaler v9.3 for these configuration steps, so other versions may have slightly different options or windows.

1. In Active Directory create a group that the members of which need to be permitted inbound access to your network. For my environment I used AccessGateway_RemoteUser. Create a service account in AD that will be used to bind to Active Directory, such as SVC_NetScaler_Admin.

2. In the NetScaler GUI go to the System folder and click on Authentication. Next, click on the Servers tab, then right click in the window and select Add.

3. Enter a name for this authentication server. I use the hostname of the AD server I’ll be authenticating against. Change the authentication type to LDAP then enter the IP address of your Active Directory server. Don’t configure the port number as we will do that later. Configure the base DN and Administrator bind DN according to your environment, and type in the password for your service account.

4. In the lower half of the window you need to configure the Search Filter and SSO Name Attribute. The search filter maybe a little confusing at first. Open option is using of memberof=cn=. If you know LDAP well you can create different filters as needed. For the SSO Name Attribute, use  samAccountName.   

5. At this point you need to configure the security for the LDAP services. The exact configuration will depend on your Domain Controller configuration. The most secure is the SSL option which uses port 636, but your DC must have a server authentication certificate. The next best is TLS, where it uses port 389 but tries to use the LDAP StartTLS command to encrypt communications.

To verify which one will work click on Retrieve Attributes under connection settings and verify a connection can be established. After you know which setting works, click OK. Note that if you use the PlainText option that the NetScaler will disable the ability of users to change expired passwords during the logon process.

6. In the NetScaler GUI go to the Authentication Policies tab, right click in the window and select Add. Input a logical name for the authentication type (e.g. Active Directory), change the Authentication Type to LDAP and pick the server name you just created.

7.  In the lower half of the window select True Value from the drop down and click Add Expressionns_true should now appear in the Expression window.

8. Your configuration should now look very similar to the window below.

9. At this point I would bind this authentication mechanism globally to the NetScaler. To do that you right click in the Policies window and select Global Bindings. Select the policy name from the drop down then click OK.

Now you are ready to rock and roll. NetScaler services such as Access Gateway can now take advantage of your Active Directory authentication services you configured. If you want to provide high availability for your authentication services, you could configure LDAP load balancing as I describe here and use that VIP instead of the IP address of your domain controller back in step 3.

LDAP Load Balancing with Citrix NetScaler v9.3

When using a load balancer in an enterprise environment it opens up the possibilities for service level redundancy that you may not have thought of before. For example, maybe you have appliance devices on the network that can be Active Directory integrated, but only allow you to specify one LDAP server (HP iLO, for example). Maybe you have multiple datacenters and you want to provide seamless datacenter failover in case of an outage for a service, such as a web site. Or maybe you have a global network and want to direct users from a particular region of the world to the nearest server to provide the best response times. Advanced load balancers can do all of this, and more.

Out of the box the Citrix NetScaler has a the capability to load balance LDAP requests, and also has intelligent monitors that do more than just see if the TCP port LDAP uses (389) is alive. The monitor can perform a query against the LDAP server to ensure the LDAP service is actually returning valid data. So let’s build a load balanced LDAP virtual server in the NetScaler and utilize the intelligent LDAP monitor provided by Citrix. A future blog article will cover the same configuration but for LDAP over SSL. These instructions are written using NetScaler v9.3, but should be fairly similar in other releases.

1. Create a service account in AD that will be used for the LDAP monitor. It should not have any special privileges. Let’s call ours SVC-NS-LDAP.

2.  Open the NetScaler management GUI and open the Load Balancing folder. Go down to the Servers container and create a new server object. Enter a logical server name. I would use the FQDN of your first Active Directory server. Next you can enter the IP address or domain name of the server. I prefer using the domain name so if a server’s IP changes you don’t wonder why your monitor or load balanced service is broken. Click on Create. Repeat the process for your other AD servers.

3. Under the Load Balancing folder on the NetScaler click on the Monitors container. Create a new monitor. On the first window enter a logical name, such as LDAP_389 and change the monitor type to LDAP. Leave all other parameters on this window alone.

4. Click on the Special Parameters tab then click on Browse and locate the script.  For the remaining fields use:

  • Dispatcher IP: (Do not change this IP)
  • Dispatcher Port: 3013 (Any unused NetScaler port will work but 3013 seems popular.)
  • Base DN: dc=contoso,dc=net (Substitute your domain information of course.)
  • Bind DN: cn=SVC-NS-LDAP,cn=users,dc=contoso,dc=net (Use your path.)
  • Filter: cn=builtin (This is a standard object in AD.)
  • Password: xxxxx (Enter the password of your service account)

Note that the filter parameter is very important so the LDAP server doesn’t return every object in your domain. You only need a single object to return from the query to ensure LDAP is working. Do NOT leave this field blank!

5. Under Load Balancing in the NetScaler GUI open the Virtual Servers container.  Add a new virtual server and use a logical name such as ldap.contoso.net_389. Change the protocol to TCP, enter the IP address of the new virtual server and use port 389. Click on the Service Groups tab and select the LDAP_389 group.

6. If all goes well you now have a functioning monitor that shows an UP state.

7. Optionally you can now create a DNS entry for the new virtual server, say, so now any devices that need load balanced LDAP services can simply point to this DNS name. Of course if the device doesn’t support DNS you can specify the virtual server IP address. Just like the rationale behind creating ‘servers’ based on DNS entries in the NetScaler, use DNS names when possible to lessen the work required when IP address changes occur.

8. To test out that the new virtual server is actually working, hop on one of your servers that has the ldp.exe tool installed. This is baked in starting with Server 2008 and later. Launch ldp then select connect. Enter the new LDAP DNS name or the virtual server IP address. Next select bind, leave the rest of the options, and click on OK. You should see messages showing the connection was successful.

9. If you want to get really geeky and verify that the search LDAP search results for the LDAP monitor are correct you can whip out WireShark and do a network trace. Look for “searchResEntry” to see the results of your query.

And there you have it! Load balanced LDAP! You should now do some testing by bringing down one of the AD servers you are load balancing across then reconnect with the ldp tool and verify you can still connect. As mentioned earlier, if your load balancer supports global load balancing, you can get really fancy and have geographically redundant LDAP. LDAPsoft also has a nifty LDAP browser you can use free for 15 days that is worthwhile to check out if you are a LDAP geek.

Updating your NetScaler Management Interface SSL Certificate

When you install the Citrix NetScaler it comes with a self-signed certificate which is bound to the management IP interface for the purposes of encrypting management traffic. However, using self-signed certificates are not recommended in anything but a lab environment. So that means you need to install and configure the NetScaler to use a new certificate for all management traffic. Thankfully Citrix has made this super easy! These steps were performed on NetScaler v9.3, other versions may slightly vary.

Here’s how!

1. Create a trusted SSL certificate and upload it to the NetScaler. The certificate should be for the FQDN that you want to use for the NetScaler management interface, not any of your Vservers. To do that follow my blog article here.

2.  In the NetScaler GUI interface navigate to the Certificates folder under SSL, right click on ns-server-certificate and verify that it is bound to several interfaces. The bindings indicate that the certificate is in use, which is good.

3. Right click on ns-server-certificate and select Update.

3. On the following screen navigate to the certificates located on the appliance that you created in step one and click OK.
4.  If the update goes as planned you will now see the new certificate names in the certificate list.

5. Close out the NetScaler management interface and reconnect via HTTPS. Open the certificate properties in your browser and verify that the trusted certificate is being used.

Load Balancing XenDesktop 5 with NetScaler 9.3

As I mentioned in yesterday’s blog post, any enterprise VDI deployment needs redundant broker services for high availability. Other enterprise applications such as Exchange, Lync, and SharePoint can all benefit from a load balancer, be it virtual or physical. Building on yesterday’s post about configuring SSL on the NetScaler, it’s now time to configure load balancing for the XenDesktop DDCs and Web Interfaces.

I’m making a few assumptions here. First, you already have XenDesktop 5 installed and functioning in your environment, hopefully with redundant WI and DDC servers. Second, you’ve configured the WI servers for SSL. Third, you’ve already deployed the NetScaler and using at least version 9.3. Fourth, you’ve installed a SSL certificates on the NetScaler for the DNS names you’ve assigned to your WI and DDC virtual IPs.

XenDesktop combo DDC/WI: and
Web Interface virtual IP:
DDC virtual IP:

1. Download the Citrix AppExpert template for the Citrix Web Interface here.
2. In the NetScaler open the AppExpert folder, right click on Templates and select Manage Templates.
3. Click on the Upload button and locate the XML file you downloaded in step one.
4. After the template imports click on Load Balancing in the NetScaler GUI. You should now see two new wizards under Getting Started.

5. Start the XenDesktop wizard and enter the appropriate information in the WI server wizard screen. The IP addresses are pretty self explanatory. I would recommend configuring a health monitoring service account. This will allow the NetScaler to actively attempt to authenticate to ensure the WI is actually functional. One critical change you need to make to the form is the site path. You MUST remove site/default.aspx, as shown below.

6. For the DDC configuration page it’s pretty clear what you need to input. Remember you will need to use a unique IP address for the DDC virtual server. And again, I’d configure a service account for health monitoring. You could use the same account or a different one.

7. Close the wizard and if everything is correct, it will create the virtual servers, service groups, monitors, and servers for you. It is very likely though that the WI monitor will show a down status, while the DDC monitor may show as UP. If that happens, it’s probably an SSL issue which we can easily resolve.

8. Open the WI virtual server  and see if you see the error below, certkey not bound,  you are in luck as this is an easy fix.

9. Click on the SSL Settings tab and select the appropriate WI SSL certificate that you either created from my blog yesterday if you are just testing, or your real one if this is a production deployment. Click on Add to move it to the configured column.

10. Close the window and now your WI State should be UP and 100% health.

11. Repeat the SSL assignment exercise for the DDC monitor using another certificate which matches the DDC DNS name you chose earlier.

Next up, open your browser and go to the FQDN for both virtual servers and verify that the XenDesktop login screen appears with no SSL warnings. If so, you’ve now created two VIPs for load balancing critical XenDesktop services and enabled health monitoring. High availability baby!

Creating a SSL certificate for Citrix Netscaler

A high availability VDI deployment, such as XenDesktop 5, demands that you use multiple servers to provide broker redundancy. As such, a load balancer such as the Citrix Netscaler comes in mighty handy. The NetScaler can also act as an ICA proxy between a trusted and untrusted network, such as the internet and your corporate network. Now that I’ve gotten XenDesktop 5 running in my lab, I wanted to see what it takes to configure the NetScaler Access Gateway feature to allow external inbound connections and serve up a nice VDI desktop.

As the configuration is somewhat complex, let’s start with the easy part, creating your own SSL certificate and importing it into the NetScaler. Now in the real world you’d need to use a trusted CA like Verisign, or your clients won’t trust the Access Gateway and the Citrix receiver will not launch. However, if you are in a lab or home environment you can use your own CA just to get the flavor how it works.

In my lab I’m using the latest NetScaler VPX release, which is v9.3 build First we need to use OpenSSL to create a private key, then a certificate request, convert the private key, then submit to my Microsoft CA, and finally import into the NetScaler. Figuring out this process was a bit easier than VMware makes it for importing certs into an ESXi host, so you have that going for you.

1. Login to the NetScaler and click on the SSL folder in the left pane.
2. Generate a private RSA key by clicking on Create RSA Key. Use a filename that is easily associated with the FQDN of the certificate and I would use a .key extension to denote it’s the private key. 2048 bits is the maximum keysize, so I’d go for that. Change the format to DER. Click on Create then Close.

3. On the NetScaler SSL page click on Create CSR. Type in a file name for the certificate request (I’d suggest a .req extension), then browse to the private key file you just created. In the Common Name field enter the FQDN you want your certificate to be bound to. Fill in the other information as needed. Click on Create then Close.

4. Back on the SSL page click on Manage Certificates then locate the REQ file, highlight it, then click on View. Copy the contents to the clipboard. Close the window.
5. Assuming you are using a Windows Server 2008 R2 CA, perform these steps:

  • Go to the certificate home page and click on Request a certificate.
  • Select Advanced certificate request.
  • Select Submit a certificate request by using a base-64-encoded….
  • Paste the certificate into the window and change the template to web server.
  • Download a DER encoded certificate (not the certificate chain) using a logical name like xd-contoso-net.cert.

6. Back on the NetScaler and open the SSL folder then click on Certificates.
7. Right click in the SSL window and select Install.
8. I would suggest the FQDN for the pair name, browse locally to the certificate file name, then browse on the appliance for the private key, and change the certificate format to DER.

9. Click on Install and hope that the certificates import successfully. Once the certificate imports, you should delete the certificate from wherever you downloaded it to on your workstation.

And there you have it! You’ve created your own private key, certificate request, generated a SSL certificate, then imported it to the NetScaler. The private key and public key file names are important, since the files are stored on the NetScaler and each certificate must have a unique name. You can repeat this process for any number of certificates, as needed.