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.