Write a comment

Many of my customers struggle when it comes to certificates, and I mean just with the basics -- not the whole PKI stuff. Netscaler is Linux-based and that seems to make it even more difficult. Not to mention, people also tend to make things more complicated than they really are. In my opinion, to understand what you are doing should be a given (at least to some degree), but many out there just want step-by-step guides that they can work through. That is my explanation why many have issues when it comes to Netscaler and Certificates.

A detailed explanation of the 'easy way' will look like it's not so easy in comparison to the step-by-step guide but once understood it will be even simpler to do.

I must assume some things and I can not start without some basic knowledge:

  1. You are mainly a Windows Administrator (Linux isn't your thing)
  2. You do know how to request a Certificate using Windows (e.g., IIS)
    Request a Server certificate using IIS (Use 2048 as bit length)
  3. You know how to use MMC/IIS to export certificates
    Export a Server certificate using IIS (Use a password with at least 5 chars!)
  4. Basic Netscaler knowledge


General Certificate requirements

For me there are two critical points when it comes to certificates:

1. Always use Full Qualified Domain Names (FQDN) like ctx.dom.com. Using host names or even worse, IP-Addresses, is a NO GO!
2. Use the current standard for the public key bit length of 2048-Bit.

You should know that the higher the bit length the stronger the security BUT, on the other hand, the compatibility with clients, devices, etc., dramatically decreases. Some years ago, the standard was 512-Bit but since Windows 95, etc., isn't used anymore it was raised to 2048-Bit. As an example, Citrix Netscaler VPX supports up to 4096-Bit for its own vServer BUT, only supports up to 2048-Bit to backend systems. 


Explaining the easy way

You can skip the explanation if you're not interested to learn what you are doing and go to the Step-By-Step guide right away.

In the following I will show the process that might look difficult, BUT take a minute to review the pictures and understand the steps required. I start at the point where you have exported a PFX file using MMC or IIS. Don't know how to do that? Then go back and see previous basic requirements points 2 and 3. I'm also breaking down the procedure in two parts and the second part is often overlooked, but it's a must do!


Part one - The Certificate

There are two steps required. First, a Certificate format 'conversion'. You exported a PFX file that is a Microsoft-based format and the equivalent Linux format is PKCS#12 that is saved as PEM. Think of it as converting a JPG image to a PNG image. Since those files include the private key, you must password protect the files (use at least 5 chars). Once in the right format you can install the certificate and that is an act of 'splitting' the file into a certificate and the private key.
Have a look at the flowchart:


Part two - The Certificate chain

Hurray! We have a Certificate in Netscaler but is it fully working? For some clients (mainly newer Windows Clients) it will work, but for all others you might get Certificate warnings or you cannot connect. Why is that? A Certificate comes with a chain and means where it comes from (like a family tree). Typically, your Certificate was created by a Certificate Authority (like a government official) and is called the Root CA. Sometimes you have something like a 'handler' that is authorized by the government and you've requested the certificate from the handler and that is called an intermediate Certificate Authority.
Now the Certificate chain is:

- Root CA (authorized)

- Intermediate CA (created)

- Server Certificate (requested by you)


When importing (converting) the certificate, normally the chain is NOT included and you need to LINK the certificates to rebuild the chain. Use Windows again to export the Root- and Intermediate Certificates in DER format. Then, just install the Certificates into Netscaler. After importing, it's very important to link the Certificates to recreate the chain.

You're done and the Certificate is ready to be bound to a Netscaler vServer.


Step-By-Step Guide

After the explanation, here is the Step-By-Step guide:

Part I (Import certificate)

  1. Export your certificate as PFX (use at least 5 chars as password)
  2. Export Root and Intermediate certificate in DER format
  3. Netscaler: Traffic Management / SSL / Import PKCS#12
    PKCS#12 file: my.cert_2016.pfx
    Output file name: my.cert_2016.pem
    Encoding Format: DES3
    Password = Passphrase <- can be the same
  4. Click OK (Converting done!)

  5. Netscaler: Traffic Management / SSL / SSL Certificates / Server Certificates
    Certificate File Name: my.cert_2016.pem
    Certificate-Key Pair Name:my.cert_2016
    Password = Passphrase
  6. Click INSTALL (You're done!)


Part II (Link Certificate)

  1. Netscaler: Traffic Management / SSL / SSL Certificates / CA Certificates
    Certificate File Name: root.ca.cer (intermidiate.ca.cer)
    Certificate-Key Pair Name: root.ca (intermidiate.ca)
  2. Click INSTALL

  3. Netscaler: Traffic Management / SSL / SSL Certificates / CA Certificates
    Select intermidiate.ca
    Click Action then select Link
  4. If the correct Root CA is available (installed) it will already show! Click OK!
  5. Netscaler: Traffic Management / SSL / SSL Certificates / Server Certificates
    Select my.cert_2016
    Click Action then select Link
  6. If the correct Intermidiate or Root CA is available (installed) it will already show! Click OK!

That's it! Now you can bind your certificate to vServer like Gateway, Loadbalancer, etc.


Helpful tips along the way

  • Use at least 5 chars to password protect PFX/PEM files that include the private key
  • Use 2048-Bit length for the public key; not more not less
  • Name Certificates file name meaningful and with a date like ctx.dom.com_11.2018
    where 11.2018 is the expiration date of the certificate
  • Backup also Certificate files from Netscaler using WinCP
  • Wildcard Certificates *.dom.com make life easier in the long run
  • Every company should have a private Certificate Authority and use SSL within everywhere!
Write comments...
or post as a guest
Loading comment... The comment will be refreshed after 00:00.

Be the first to comment.