Citrix NetScaler… The basics continued, part four. What about SSL?

I think we all know port 443 and the SSL (Secure Socket Layer) protocol that goes with it right? When securing our inbound (incoming) as well outbound (outgoing) network traffic we have to deal with things like certificates, public and private key’s, certificate authorities (CA), and so on and so forth. This can be confusing. Where do certificates get applied, what is a CA, what types of certificates are there and which ones do we use? Also, once applied, how does the NetScaler actually know who it is communicating with and how is traffic secured? Using the NetScaler to offload SSL you say? Let’s have a look.

Other (related) articles from these series include:

1. Citrix NetScaler Gateway, the basics!
2. Citrix NetScaler (10.5) licensing. What’s new with Access Gateway!
3. Citrix NetScaler… The basics continued, part one. VIP’s, Monitors and other objects!
4. Citrix NetScaler… The basics continued, part two. Static routes, SNIP and MIP!
5. Citrix NetScaler… The basics continued, part three. High Availability!
6. Citrix NetScaler… The basics continued, part five. Global Server Load Balancing!
7. Citrix NetScaler… The basics continued, Part six. Content Switching!
8. Citrix NetScaler… The basics continued, part seven. Split Tunneling!

In short…

When connecting from a remote location we want to make sure that we are connecting to the trusted company network and that it isn’t being spoofed in any way. In our case (and for the purposes of this series) we would setup the Citrix NetScaler to function as a remote secure gateway (virtual server) as the first point of access, authenticating and authorizing our users. However, the question remains, how does the user know, after filling in the external facing URL of the NetScaler, that it is connecting to the actual (trusted) company network and that the machine answering the request is who it says it is? This is where certificates come into play.

I’ll need some proof of that

The NetScaler will have a SSL certificate installed, which it uses to identify itself to the remote user / machine, convincing them that it is who it says it is, the certificate is (or should be) prove of that. Now I know, anyone can forge or counterfeit a digital certificate, so there needs to be a of mechanism in place which tells the end-user / machine that it can trust the certificate presented by the NetScaler during the setup and negotiation of the remote connection. Enter the Certificate Authorities (CA).

How to get some

Certificates can be acquired, generated or purchased in multiple ways. For example, you can set up your own internal domain based PKI, Public Key Infrastructure, and start handing out certificates. This way you create your own internal Certificate Authority. This can also be done on the NetScaler by the way. You can also generate so-called self-signed certificates, which are issued by the machine itself. This basically means that the machine generating and signing the certificate trusts itself, duh. This can be done on the NetScaler as well. Or, last but not least, you can purchase a certificate from a well known, respected and most importantly, trusted external third party Certificate Authority.

A short resume, a certificate is always issued and signed by a Certificate Authority of some sort. This can be an private CA when you set up and configure your own internal PKI for example, a self signed certificate as mentioned above, where the machine issuing the certificate is basically its own CA (it can’t assign certificates to other machines), or the CA can be external, a third party as I also highlighted.

Who trusts whom?

When a user / machine connects to an external resource like a NetScaler (Gateway) for example, the external resource will present a certificate to try and proof that it is who it says it is. As mentioned, certificates are issued and signed by so-called CA’s. And here it comes, the CA who originally issued (and signed) the certificate to the external resource needs to be trusted by the user / machine (or client) connecting to that resource. If the CA is trusted all is fine and you will end op on the webpage you requested. If the CA who issued the certificate of the external resource is not trusted by the client you will end up with a security warning as shown below where you need to decide to continue or not. These may differ slightly depending on the browser type and version used.

Another example would be when the NetScaler communicates with one of your StoreFront servers (or vice versa), here SSL encryption can be applied as well. In this case the NetScaler will connect up to the StoreFront server requesting a secure connection to exchange information. The Storefront server will show the NetScaler its SSL Cert. to prove that it is who it say’s it is. In this case the NetScaler will need to trust the CA, which issued and signed the StoreFront certificate. Same rules apply.

The advantage of purchasing certificates from a well-known third party CA is that all major web browsers, by default, already trust these companies / CA’s. So when you connect to a website / resource showing you a certificate issued and signed by a well-known third party CA you will not have any issues getting onto the actual webpage you requested.

Or… sort it yourself

If you don’t use a third party trusted CA you will need to come up with a way to make all of your users / devices trust your internal CA for example. Of course this is doable, but it involves some extra effort, which, depending on the number and types of external users / clients, can be a daunting task. The same applies to self signed certificates, you will need to make sure that your users / clients trust the machine (CA) that issued the self signed cert.

External CA’s have a very extensive and intensive authentication and verification program you will need to go through before they give out one of their certificates. This is one of the main reasons why these CA’s are trusted within most major web browsers, as mention earlier. The cost per cert. can greatly vary per vendor and the type of certificate you want to purchase. Also, the time a certificate will be valid will have an influence on the overall costs as well. Some well know CA’s are: GoDaddy, VeriSign, GlobalSign, DigiCert etc. If you give it a Google you’ll come up with a few more I’m sure.

A bit more on the SSL negotiation process

Now that you know about the main reason behind certificates and how they are issued and signed, let’s have a look at the actual negotiation process when a remote secure connection is being set up. When a session gets established a lot happens under the hood, which is also referred to as the SSL Handshake.

SSL primarily uses symmetric encryption, which consists of a shared key pair used for both encryption and decryption when exchanging data between client and server systems. I say ‘primarily’ because during the initial SSL Handshake asymmetric public key encryption is used.

Symmetric encryption is considered less secure than asymmetric encryption, however, it’s much faster and thus far less resource intensive when it comes to encrypting and decrypting data, a trade off between the two you could say.

Although, once the connection is established, SSL traffic is symmetrically encrypted, SSL connections are still prone to performance degradation and overall slowness because of the Handshake process involved. As mentioned, during this phase asymmetric public key encryption is used, which is much more resource intensive. The server needs to be authenticated as well as the client when two-way authentication is applied, impacting overall performance significantly. This is where SSL Offloading and Acceleration might be helpful, more on this in a bit.

Public and private keys

Key pairs work like this. The SSL certificate holds a public and a private key, also known as the key pair. The private key will never be shared or shown to or with anyone else. The public key however, is send as part of the initial session negotiation process (Handshake) so it can be used to encrypt the pre-master secret as part of establishing a secure SSL connection, see the overview below. Once the pre-master secret is send, the encrypted data can only be decrypted by the private key as part of the key pair. This is what happens…

This is what happens (source: Symantec.com / slightly altered)

1. Client Hello
   – Information that the server needs to communicate with the client using SSL.
   – Including SSL version number, cipher settings, session-specific data.
2. Server Hello
   – Information that the client needs to communicate with the server using SSL.
   – Including SSL version number, cipher settings, session-specific data.
   – Including Server’s Certificate (Public Key)
3. Authentication and Pre-Master Secret
   – Client authenticates the server certificate. (e.g. Common Name / Date / Issuer)
   – Client (depending on the cipher) creates the pre-master secret for the session,
   – Encrypts the pre-master secret with the server’s public key and sends it back to the server.
4. Decryption and Master Secret
   – Server uses its private key to decrypt the pre-master secret,
   – Both Server and Client perform steps to generate the master secret with the agreed cipher.
5. Generate Session Keys
   – Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session
6. Encryption with Session Key
   – Both client and server exchange messages to inform that future messages will be encrypted.

Types of certs.

When creating or requesting a digital SSL certificate you have a few options. Of course you can decide on the lifespan of the certificate, 2 years, five years and so on and so forth, the number of bits used for encryption etc. but there are some other variables you may want to consider, two in particular.

Let’s get wild

For example, we could make use of a so-called wild card certificate. A wild card certificate can be used on multiple devices / machines without having to purchase or generate multiple separate certificates. So instead of generating or purchasing two separate certificates for your NetScaler and your StoreFront server, like, external.vankaam.local and storefront.vankaam.local, we could do with just one in form of *.vankaam.local. It basically supports an unlimited number of subdomains.

It is seen as an overall best practice to use separate third party certificates when dealing with external – inbound connections, and use internal CA certs, in the form a wild card cert for example, when dealing with internal SSL traffic. 

SAN certificates

Another one I’d like to highlight is the SAN, or Subject Alternative Name, certificate. A SAN certificate can be used to secure multiple domains like, vankaam.com, basvankaam.org mydomain.com etc. I think you get the point.

SSL offloading using the Citrix NetScaler

One of the virtual server types you can create and configure on the NetScaler is an SSL Offload virtual server. You can probably image having multiple internal web servers accessible through your NetScaler, never mind what type of service they have to offer.

By default, the web server hosting the certificate handles all decryption and encryption of SSL traffic, potentially burdening the server with extra load. This could, when traffic is heavy, impact performance since decrypting and encrypting network traffic can be a CPU-intensive task, particularly during session initiation a.k.a. the Handshake which also includes the server to client authentication, and vice versa, as explained earlier. By implementing SSL Offloading you basically delegate these tasks, of handshaking, decrypting and or encrypting traffic to a third party device (our NetScaler) automatically freeing the web server from (extra) load.

No servers in DMZ

Another advantage is that the device responsible for Offloading all SSL traffic, the Citrix NetScaler in our case, can live within our DMZ, the way we like it. And the web server(s) for which SSL traffic is being offloaded can be safely placed on our (more secure) internal network (although this doesn’t apply to all use cases of course) without having to worry about unsafe connections since, next to user authentication (when applicable) which can be handled by the NetScaler as well, all traffic can be checked, inspected, decrypted and possible (re)encrypted by the NetScaler before finally ending up on the web server. Do note however, that additional configuration steps will be needed to achieve all this. Simply enabling and configuring SSL Offloading won’t be enough.

Note that as soon SSL traffic gets decrypted, inspected etc. on the NetScaler you can decide to send it through as regular HTTP traffic, or to re-encrypt it and send it over HTTPS (port 443) a.k.a. end to end encryption, but that’s up to you. When dealing with the NetScaler gateway for example it is not uncommon to offload at NetScaler level and send plain HTTP traffic on to your StoreFront servers. Also, when offloading large amount of SSL traffic, you might want to consider an MPX (physical) NetScaler appliance, these contain a dedicate physical chip specifically designed for these (decrypting / encrypting) purposes.

Wrap up

That’s about it with regards to SSL and the NetScaler as far as I am concerned. Hopefully this kind of gives you an overview on some of the options you have certificate wise and how things operate from a technical perspective. Here I’d also like to point out another SSL related blog written by Esther Barthel not that long ago, you’ll find it here. It will tell and show you how certificates are generated, what types of certificate formats there are, including some of the coding formats that go with it.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.