Back-End Connection on TLS 1.1/1.2 from NetScaler to IIS Servers Break

Back-end connection on TLS 1.1/1.2 from NetScaler to IIS servers break.

The server Event Viewer has the following logs:
Event ID: 36874- TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

Citrix is aware of this issue and it is being tracked with issue ID #0600155. The fix for this issue will be delivered in a future maintenance release.
NetScaler will send signature algorithm extension in the client hello.

Workaround

Complete the following procedure to workaround this issue:
On NetScaler, disable TLS 1.2 on back-end SSL service/service group. This also takes care of the secure monitor SSL handshake.
>?? set ssl service <service name> -tls11 DISABLED -tls12 DISABLED
??
For SSL bridge and dynamically learnt services (used primarily in Gateway deployments), add the following parameters. This will disable TLS 1.1/1.2 globally for all SSL services. These parameters are available in NetScaler 11.0 64.x and NetScaler 10.5 60.7.
> set ssl parameter -svctls1112disable enable -montls1112disable?? enable

The latest IIS servers with TLS 1.2 support mandates “Signature Algorithms” extension in the client hello to complete the TLS 1.2 handshake. Currently NetScaler does not send this extension.

The problem occurs because of the way in which Microsoft has implemented TLS1.2 support in SCHANNEL. When the NetScaler is sending the SSL ClientHello, we are not specifying any “Signature Algorithms” in our part of the handshake. The is perfectly valid from an RFC perspective, and the RFC for TLS1.2 dictates the following: https://tools.ietf.org/html/rfc5246#section-7.4.1.4??

If the client does not send the signature_algorithms extension, the??
server MUST do the following:??

- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,??
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had??
sent the value {sha1,rsa}.??

- If the negotiated key exchange algorithm is one of (DHE_DSS,??
DH_DSS), behave as if the client had sent the value {sha1,dsa}.??

- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,??
ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

So the SCHANNEL is using the above and behaving as if the NetScaler had specified “sha1,rsa”. However, IIS is incorrectly assuming that the NetScaler can ONLY understand SHA1, and does not understand SHA256. Since the Certificate installed has a SHA256 signature it would be therefore be impossible for the SSL connection to continue, which is why the request is terminated by SCHANNEL.

Starting from 10.5 59.11 build, NetScaler supports TLS 1.1/1.2 on the back-end communication on all hardware platforms (MPX, SDX, MPX-FIPS). The implementation is per RFCs. But, some back-end servers may not completely comply to RFC defined SSL handshake behavior. In this case, IIS servers mandate client to send signature extension in client hello which NetScaler does not send (see RFC 5246 - 7.4.1.4.1. Signature Algorithms). Citrix is working on sending the required extension in client hello. Refer to the solution section for the workaround to this issue.

The two parameters (svctls1112disable and montls1112disable)?? cannot be disabled from CLI. If you must disable them, then edit the configuration (ns.conf) file as follows:

1. Remove these parameters from the "set ssl param” command.
2. Save the configuration.
3. Restart the appliance.