Recently I implemented a Citrix NetScaler environment at a Dutch insurance company. This company uses Citrix NetScaler as a reverse proxy for various web-based applications. One of these applications is using public signed client (user) certificates. Based on the client certificate information a user will get a specific role assigned within the web app.
This web app traditionally requires a client certificate to process the user request to the web app content. This means with Citrix NetScaler we where not able to perform SSL offloading techniques because the web app requires a real client certificate presented by the client (user). Unfortunately we had to create a SSL bridged virtual server to offer the client certificate via Citrix NetScaler.
We advised the web app developer to dive into the process to change the authorization from a client certificate to HTTP header (where we can put the client certificate into via Citrix NetScaler).
Two weeks ago I got a call that the web app authorization process has been changed successfully. Time to get rid of that nasty SSL bridged traffic where Citrix NetScaler can’t dive into.
SSL Server Certificate Offloading
First we created a SSL based virtual to replace the SSL_BRIDGE virtual server:
batch Command: add lb vserver VIP-WebApp-A SSL 192.168.2.120 443 -comment "VIP used for web app A; Including SSL offloading"
Next we bind a HTTP based service to the SSL based virtual server. This can be a SSL based service too, but hey we want to show the power of SSL Offloading:
batch Command: bind lb vserver VIP-WebApp-A svc-webapp-a
As you have noticed the virtual server is still marked as “down” while we haven’t bind a server certificate i.e. the FQDN cannot be validated against the SSL based virtual server. Let’s bind a server certificate:
batch Command: bind ssl vserver VIP-WebApp-A -certkeyName WebApp-A-Server
We now do have a regular SSL based virtual server online where we applied SSL Offloading to the web app server because of the HTTP service:
SSL Client Certificate Offloading:
Because the web app now do expect the client certificate information in the HTTP header we have to enable client (user) certificate authentication and create SSL Policy to let Citrix NetScaler put this information into the HTTP header.
First we need to enable client certificate authentication on the SSL based virtual server:
batch Command: set ssl vserver VIP-WebApp-A -clientAuth ENABLED -clientCert Mandatory
When browsing to the SSL based virtual server a user is now prompted which certificate to use for authentication:
Next step is to bind the root certificate to the SSL based virtual server. This step is needed to validate the client (user) certificate against the root CA.
batch Command: bind ssl vserver VIP-WebApp-A -certkeyName public-a-caroot –CA
When browsing to the SSL based virtual server a user is now prompted which certificate to use for authentication, however only the client (user) certificate is shown that is signed by the root CA that is bind to our SSL based virtual server:
After this step client (user) certificate authentication is enabled as well. Please note that this authentication now only take place at the SSL based virtual server. After successful authentication any connection is forwarded to the web app server, without any client certificate.
Forward client certificate information via HTTP header
To be able to authorize a user based on the client (user) certificate information we do want to forward this information from the SSL based virtual server to the web app server. This is where we can use SSL Policies.
First we are going to create a SSL Action to specify what information we want to forward to the web app server in the HTTP header:
batch Command: add ssl action SSL-Action-Forward-ClientCertInfo -clientCertSubject ENABLED -certSubjectHeader Client-Cert-Subject -clientCertIssuer ENABLED -certIssuerHeader Client-Cert-Issuer
Then we need to create a SSL Policy to specify under what circumstances this SSL Action needs to be fired:
Note that I used a expression where we filter on a specific certificate issuer (Root or Intermediate CA). This is very important and allows us to filter on when to forward the offloaded client (user) certificate to the web app server and when to forward not!
batch Command: add ssl policy SSL-Policy-Forward-ClientCertInfo -rule "CLIENT.SSL.CLIENT_CERT.ISSUER.CONTAINS(\"Public A CA Root\")" -action SSL-Action-Forward-ClientCertInfo
Next we need to bind this SSL Policy to the SSL based virtual server:
batch Command: bind ssl vserver VIP-WebApp-A -policyName SSL-Policy-Forward-ClientCertInfo -priority 1
Lets have a look at the web app server if the HTTP headers are present. For this I make use of WireShark:
With this configuration the web app developer is able to authorize a user based on the client certificate subject, or parts of the subject like the Common Name(CN) or emailAddress.
If the user is authenticated with a client certificate that was signed by another Certificate Authority then specified in the SSL Policy expression we don’t forward the client certificate via HTTP header. This means the authorization will fail and the developer can redirect the request to a landing or guest page.
Last but not least keep in mind to secure any SSL based virtual server, for more information on that topic check this blogpost: http://www.antonvanpelt.com/make-netscaler-ssl-vips-secure/