This issue only occurs when using Internet Explorer with NetScaler. When NetScaler performs Client Certificate authentication, the SSL Handshake between the client and server fails if the protocol used is TLS 1.2.
Scenarios tested where Client Certificate authentication succeeds:
- Using IE8, IE11 and Edge with TLS 1.2 and SHA256 signed certificate – Client Auth set to Optional or Mandatory.
- Using IE8, IE11 and Edge with TLS 1.2 and SHA1 signed certificate – Client Auth set to Mandatory.
- Using Chrome with TLS 1.2 and SHA1 signed certificate – Client Auth set to Optional or Mandatory.
- Using IE8, IE11 and Edge with TLS 1.0 or 1.1 and SHA1 signed certificate – Client Auth set to Optional or Mandatory.
Scnearios tested where Client Certificate authentication fails:
- Using IE8, IE11 and Edge with TLS 1.2 and SHA1 signed certificate – Client Auth set to Optional.
NetScaler builds tested:
- NS 11.1 51.21
- NS 11.1 49.16
- NS 11.0 64.34
When a client connects to NetScaler Gateway, an SSL handshake is performed. The client sends a Client Hello to NetScaler.
The Client Hello message contains the TLS protocol and cipher suites the browser can support.
The message back from NetScaler, Server Hello agrees on a TLS protocol and cipher suite that is supported both by the client and server. 
The NetScaler then requests the client to identify itself by form of certificate. 
The certificate is sent from the client over TLS 1.2. However notice the following:
Certificates Length: 0 – This indicates no certificate was actually sent by the client to the NetScaler. So, authentication fails. This behavious was witnessed using IE11, when TLS 1.2 was negotiated between browser/server and a SHA1 signed certificate from a Microsoft internal CA was being selected by the client when prompted by NetScaler to provide a certificate.
The NetScaler Client Authentication mode was also set to Optional. This means because the certificate was not sent to NetScaler in the first instance, the client is not asked again and fails certificate authentication. At this stage the client does a GET request to NetScaler for the index.html page. The session uses TLS 1.2 however client certificate authentication has failed and the user will have to authenticate by other means.
The following behaviour is noted when using the same SHA1 certificate, IE11 and NetScaler Client Authentication set to Mandatory. The first handshake occurs.
TLS 1.2 with the TLS_RSA_WITH_AES_256_CBC_SHA Cipher Suite is agreed upon. 
Now the client and server both fail the SSL handshake with a Handshake Failure fatal alert. 
However with Mandatory, certificate authentication must be successful so a client/server renegotiation takes place. 
This time, because TLS 1.2 has failed, the client advertises the TLS 1.0 protocol and cipher suites it supports. It could have used TLS 1.1 but the browser I used had TLS 1.1 unticked.
From NetScaler TLS 1.0 is agreed and the NetScaler picks cipher suite TLS_RSA_WITH_AES_256_CBC_SHA. 
The certificate is sent by the client without issue, over TLS 1.0. The session herein between client and server uses TLS 1.0. 
Now that we have identified that the issue relates to sending a SHA1 certificate over TLS 1.2 with IE, you could within IE disable TLS 1.2. This is not recommended however because all subsequent websites you visit using IE will never use TLS 1.2. 
Instead, you can disable TLS 1.2 at the NetScaler Gateway vServer level.
If you are using an SSL Profile, disable TLS 1.2 in the profile that is attached to your NetScaler Gateway vServer instead. The SSL Profile is used to configure such settings rather than editing SSL Parameters on the NetScaler Gateway vServer.
The best fix though is to upgrade internal certificate authorities to sign certificates using sha265 as below. SHA1 is now deprecated publicly with internal only being supported for now to give administrators time to re-issue all internally deployed certificates.
hqt
February 20, 2018I am seeing this problem with the Citrix Receiver client for Windows 10. I am getting TLS errors because the client appears to not send a certificate to the NetScaler.
Certificates Length: 0
Have you tested using Ctirix Receiver? Thank you.
George Spiers
February 20, 2018Are you using SHA1 certificates? I would expect the same behaviour regardless of client or web browser.
Kari Ruissalo
February 27, 2018Hi George,
Once again, an awesome article. Thank you!
We’re seeing a really weird issue with certificate authentication in a customer environment. I even built the similar setup in to my lab and that one works. The differences between my lab and the customer environment are that lab has XA 7.x and the customer is running 6.5. Also, they have a root + intermediate structure with their internal CA that hands out the user certificates. Both environments are using sha-1 signed certs and have TLS 1.2 disabled. The environment is also built as “Unified Gateway” so there’s a CS vServer in front of the GW.
It works in the lab and at the customer we just end up with “Unable to connect to the server. Contact your system administrator with the following error: SSL Error 14: None of the SSL cipher suites offered () were accepted by the server.” We get authenticated all the way to the StoreFront but the application launch fails (where the Receiver steps in).
When we traced this, we’re seeing that TLS1.1 is being used, but when the CS VIP is sending certificate request and the client responds this with incomplete request and we get reset code 9951.
I’m thinking of removing the CS vServer from the equation and seeing if that helps. I also have a ticket open in support, but so far we haven’t been able to find anything. If you have any ideas what to test, they’re more than welcome!
George Spiers
February 27, 2018Are you using StoreFront, but a 6.5 farm? So no Web Interface?
Create a new NS Gateway (not Unified) but set it to use the same VIP as the Content Switch. On this new NS Gateway vServer, Client Certificate authentication is switched OFF. On the Unified Gateway vServer, it is still switched ON. Set the port on the new NS Gateway vServer to :444.
Now edit StoreFront and the NetScaler Gateway settings and change the NetScaler FQDN so that it remains the same, but it uses :444. So for example, https://NSG.com:444. Propagate changes to all StoreFront servers.
Try to authenticate to https://NSG.com:443 and then launch an application. StoreFront should send launch.ica to client with proxy host as the :444 URL with Client Auth switched off.
Kari Ruissalo
February 28, 2018No Web Interface, we’re updating the access layer components (replacing TMG + SGW with NetScaler and WI with SF).
About the other GW, that’s not a bad idea actually. I don’t think we’ll end up using port 444 or anything custom but another name, so that the users would log in to https://login.company.com and their sessions would then use sth like https://icaproxy.company.com for establishing the sessions.
Thank you for the answer! Keep up the good work 🙂
Kari Ruissalo
March 1, 2018Ok… so the same host name is vital for the SSO to work properly. I created another GW vServer with same IP in port 444, bound the same service certificate (not the auth) to the vServer, added the same STA. In StoreFront configuration I changed the NetScaler GW URL from https://gw.address.com to https://gw.address.com:444.
When I try to launch the session I’m getting this error:
“Unable to connect to the server. Contact your system administrator with the following error: The Citrix SSL server you have selected is not accepting connections.”
I can see in TCPView that it’s trying to connect in port 444, but the session is not established.
The customer problem seems to be related to the cryptographic provider they’re using (https://support.citrix.com/article/CTX209378) with their present certs.
Kari Ruissalo
March 1, 2018Nevermind. I had entered a wrong IP for the “passive” GW (copied the one with wrong IP).