Back-end connection on TLS 1.1/1.2 from ADC to IIS server breaks.

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.

This issue is fixed in ADC 12.0 GA build and higher.

Workaround

Complete the following procedure to workaround this issue:
On ADC, 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 ADC 11.0 64.x and ADC 10.5 60.7.
> set ssl parameter -svctls1112disable enable -montls1112disable enable

Note: If you are completing this procedure using the GUI management page, then ensure to verify if the configuration parameters appear disabled. It has been noticed that in some builds when completing the procedure using the GUI management page, the parameters are not saved to the configuration.

Problem Cause

The latest IIS servers with TLS 1.2 support mandates “Signature Algorithms” extension in the client hello to complete the TLS 1.2 handshake. ADC on version below 12.0 is not capable of sending Signature Algorithms. 

Cause Explanation: 

The problem occurs because of the way in which Microsoft has implemented TLS1.2 support in SCHANNEL. When the ADC 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, then behave as if the client had sent the value sha1,rsa.
- If the negotiated key exchange algorithm is one of DHE_DSS, DH_DSS, then behave as if the client had sent the value sha1,dsa.
- If the negotiated key exchange algorithm is one of ECDH_ECDSA, ECDHE_ECDSA, then behave as if the client had sent value sha1,ecdsa.

So, the SCHANNEL is using the above and behaving as if the ADC had specified “sha1,rsa”. Since the Certificate installed has a SHA256 signature it would 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, ADC supports TLS 1.1/1.2 on the back-end communication on all hardware platforms (MPX, SDX, MPX-FIPS). ADC VPX supports TLS 1.1/1.2 on the back-end communication starting with 11.0.66.11 ( ADC VPX on build prior to 11.0.66.11 does not support TLS 1.1/1.2 for the back-end communication) Please refer to the link below for more information on supported protocols and ciphers by the ADC Appliance. The implementation is per RFCs. But, some back-end servers may not completely comply with RFC defined SSL handshake behavior. In this case, IIS servers mandate the client to send a signature extension in the client hello which ADC does not send (see RFC 5246 - 7.4.1.4.1. Signature Algorithms). Citrix is working on sending the required extension in the client hello. Refer to the Solution section for the workaround to this issue.https://docs.citrix.com/en-us/citrix-adc/12-1/ssl/ciphers-available-on-the-citrix-ADC-appliances.html

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

Backend Connection Over TLS 1.2 Fails When SHA384/512 Certificate Is Bound on IIS Server:

An issue on ADC appliances using TLS 1.2 on backend connections has been reported to ADC Engineering. SSL handshake failure is seen on the backend when Microsoft IIS web servers have a greater than SHA256 based server certificate bound.

This is expected behavior if you are running ADC release 11.0 because only SHA256 signed-certificates are supported on the back end of all appliances.

Support for SHA384 and SHA512 certificates on the back end have been added in release 11.1 54.X. Refer to Note 3 on https://docs.citrix.com/en-us/netscaler/12/ssl/cipher_protocl_support_matrix.html