Recenlty I have been involved at a customer where we deployed a new NetScaler pair with the latest and greatest firmware version. We ran into an issue with certificates. In this blog I will talk about the issues we ran into and how you can solve them.

When running NetScaler firmware 12.1.48.13 and you want to install a PFX certificate there is a possibility that you receive the following error (No certificates present in the certificate bundle file):

If you do succeed to install the PFX on NetScaler you might get an error whilst binding the certificate to a vServer:

Certificate is not server certificate

 

These errors seem to be a bug in the GUI of NetScaler. You can solve this by doing the following:

  • Upload the certificate file to /nsconfig/ssl
  • SSH into NetScaler and run: add ssl certkey <name_of_certificate> -cert /nsconfig/ssl/<Name_of_pfx> -key /nsconfig/ssl/ <name_of_pfx) -password <enteryourpasswordhere>

After running this on the CLI you are able to bind your certificate to vServers again.

Hope this helps you in adding certificates to your NetScaler again!

<UPDATED: 24-07-2018 - Changed command to add ssl certkey due to recent comments, my bad, I think it was a typo! </UPDATED>

 

Write comment (14 Comments)

In a previous blog I wrote about adding a footer to the NetScaler gateway. Since that post Citrix included the RfWebUI theme

Citrix has posted a support article how to add a footer to this theme.

Specifically from that article the following piece of code is extracted

add rewrite action rw_act_insert_loginfooter_2 insert_after_all "HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)" q{"(\"<div style='text-align:center;color:white;font-size:15px;'>Experiencing technical difficulties?<br>Open the"+" <a style='color:white;text-decoration:underline' href='http://citrix.com'>Citrix Guide</a> or Report an issue to the"+" <a style='color:white;text-decoration:underline' href='mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.'>Citrix Support</a>team</div>\")"} -search "text(\"customAuthBottom\")"

add rewrite policy rw_pol_insert_loginfooter_2 "HTTP.REQ.URL.CONTAINS(\"/LogonPoint/index.html\")" rw_act_insert_loginfooter_2

Sticking to that code you will end up with the following

Actually the lines from the article of Citrix should be changed, whereas

<a style='color:white;text-decoration:underline' href='mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.'>Citrix Support</a>team</div>\")"}  is used it should be:

<a style='color:white;text-decoration:underline' href='mailto:This email address is being protected from spambots. You need JavaScript enabled to view it.'>Citrix Support</a> team</div\")"

When that is applied there will be no text visible that is not wanted or accounted for.

You will end up with this:

For every theme it is possible to add a footer to the login box. Which makes the need for manually customizing the portal theme less relevant and thus makes customizing the NetScaler portal more sustainable. That is a good thing if you ask me.

Write comment (0 Comments)

My colleague Arno Meijroos was at a customer where they were experiencing disconnects when using Citrix Receiver 4.6. When the customer used Receiver 4.5 no disconnects occured.

NetScaler was running on Firmware version 11.1.50.10. An MPX was used.

Whilst looking at trace files on NetScaler and Client side all that was noticable was that the connection was terminated on the NetScaler side.

On the NetScaler custom cipher suites were defined to get an A+ rating in SSL Labs.

After working a little with Citrix Support they came with the following work-around:

Unbind the following ciphers from the custom cipher suite.

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

After removing these two ciphers from the suite no disconnects happen anymore.

 

For now I would advice to stay on receiver 4.5 or if there is any need for receiver 4.6 remove the ciphers as described above from your cipher suite.

Write comment (2 Comments)

Recently I have been involved at a customer where we did the NetScaler Gateway implementation. Our good practise is to make sure that we lease the internet accessible IP's with atleast an A rating in SSL Labs.

At the customer I was involved a Pentest was conducted. The pentest was pretty thourough (as expected) and came with a few recommandations. A few of the recommandations related to the HTTP header the NetScaler sends back. This article describes the headers and how to modify this with NetScaler.

 

Content Security Policy

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

How to solve this:

 

add rewrite action rw_act_insert_CSP_header insert_http_header Content-Security-Policy "\"default-src \'self\' ; img-src \'self\' \'data\' ; connect-src \'self\' \'wss\' ; report-uri https://report-uri.io/report/URL;\""

add rewrite policy rw_pol_enforce_CSP TRUE rw_act_insert_CSP_header

Public key pinning

HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.

How to solve this:

add rewrite action rw-act-PublicKeyPin insert_http_header Public-Key-Pins q{"pin-sha256=\"<HASHPRIMCERT>\"; pin-sha256=\"<HASHINTERMEDIATECERT>\"; max-age=2592000; includeSubDomains"}

add rewrite policy rw-pol-publickeypin true rw-act-PublicKeyPin

X-XSS-Protection

This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header are 0, which disables the protection, 1 which enables the protection and 1; mode=block which tells the browser to block the response if it detects an attack rather than sanitising the script.

How to solve this

add rewrite action rw-act-insert-XSS-header insert_http_header X-Xss-Protection "\"1; mode=block\""

add rewrite policy rw-pol-enforce-XSS TRUE rw-act-insert-XSS-header

X-Content-Type-Options

Nice and easy to configure, this header only has one valid value, nosniff. It prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server. It reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as a different content-type, like an executable.

How to solve this:

add rewrite action rw-act-insert-XContent_header insert_http_header X-Content-Type-Options "\"nosniff\""

add rewrite policy rw-pol-enforce-XContent TRUE rw-act-insert-XContent_header

 

Now that all policies and actions are in place we need to bind them to the vServer. Bind them as rewrite/response policy and use the goto expression of next, to make the policy processing continue after applying.

After applying the policies, head over to securityheaders.io hit the URL of your website and see the results:

 

 

 

Write comment (4 Comments)

This week I was at a customer to help them with a NetScaler upgrade. The customer was on a 10.5 firmware and wanted (had to) upgrade to 11.1. So far no problem there.. They have a NetScaler Acces Gateway license, no problem either.. They wanted customization on the Gateway portal, hey no problem. They wanted some links and text on the gateway portal, no problem. Uuuh problem!

After upgrading the secondary appliance, failing it over and applying the rewrite rules, nothing appeared on the Gateway portal..

I suspected Integrated Caching.. As I said, the customer has a NetScaler Access Gateway license. This does not support Integrated caching. When viewing the unlicensed features and looking at Integrated Caching, I did see hits on the default cache groups.

What I did to solve the issue is I went to the gateway portal, opened up the caching policies

Opened the _cacheVPNStaticOBject

And changed the Actions to NONCACHE

After exiting the Gateway Portal setup and refreshing the portal through the internet the rewrite rule was working. As last action I have set the Caching policy back to CACHE.

Write comment (2 Comments)