Jump to content
Updated Privacy Statement

Netscaler 12 & RFC 5746 on Backend: Bug / limitation

Recommended Posts

There is a Netscaler Bug or undocumented limitation in regard to RFC 5746 on Backend.

I have been struggling with Back End TLS with latest Netscaler 12 when talking to Windows Servers that have applied TLS Hardening.


If Windows Servers have this registry setting: (Tested on 2008 R2 and 2012 R2 )






Netscaler Services will fail to communicate with them no matter what settings you use on “Secure Renegotiation” in my SSL Profiles.


If I however delete the registry settings so that Windows Servers Allows Insecure Renego it works fine.


Reading RFC 5745 I am guessing Netscaler does not utilize RFC 5746 Extension properly in the “TLS Client Hello” resulting in a TCP Reset from the Windows Servers.

Link to comment
Share on other sites

  • 1 month later...

I think this is more a limitation, than a bug. If subkey is set to 0, Windows seems expect the client to signal support for secure renegotiation as per RFC 5756. It seems Netscaler does not support renegotiation on backend, and therefore does not signal anything. I do think this is correct behavior from Netscaler. I solved my issue by setting subkey to 1 (disable renegostiation) on Windows.

Link to comment
Share on other sites

  • 5 months later...



We checked and secure renegotiation isn't required on the IIS backend (keys are not present).


We found the issue. Basically Netscaler VPX will always use the same 19 chiper suites for backend communication for SSL VPN and SSL Monitors regardless what you configure on the vServer, Service or default SSL profiles. Those are:




Unfortunately this list doesn't include any TLS 1.2 chipers which are regarded as SSLLabs A(+) grade chipers like those listed in Citrix's own blog: https://www.citrix.com/blogs/2016/06/09/scoring-an-a-at-ssllabs-com-with-citrix-netscaler-2016-update/.


Since all ECHDE chipers are not available for SSL VPN and monitors and





are also not part of this list, it will become increasingly difficult for customers to use gateway or monitors to connect to hardened SSL backends which have been configured to score an SSLabs A+ rating in the first place.


Since this list of recommended chipers in the blog is rather widespread I suggest that Citrix adds support for those to fix the issue as turning of TLS 1.1 and 1.2 on the backend can only be a workaround but not the sultion.






Link to comment
Share on other sites

If you followed that citrix persons reccommendation in the other thread he gave you commands that disables TLS 1.1 & 1.2 on backend. did you re-enable it again ? 

I can do TLS 1.2 perfectly fine on VPX towards IIS. 


I know IIS by default does not utilize reneg but if you follow / implement their best practise guides or run any of the IIS "Best Practise" tools Reneg will be enabled on IIS. 

Hence it is not possible for Netscaler to talk to a Microsoft IIS implemented after Microsofts Best Practise Guides due to Renegotiate. 

Link to comment
Share on other sites


27 minutes ago, Kai Thorsrud1709157845 said:

You can score A+ with a VPX. Applications and users connect to Front End not Back End. 


of course, but you got me wrong. If the backend is already configured for A+ Netscaler VPX cannot connect to it using SSL. If Netscaler is used for SSL VPN, for ex. SecureWeb Micro VPN and the Website is an intranet application proxied through Netscaler Getway. it won't work unless you add one of the chipers on the website backend or you are SSL bridging a Sharepoint farm and cannot setup a SSL monitor if the cipher is missing.

Link to comment
Share on other sites

  • 5 months later...
  • 2 years later...

After upgrading to latest 13.0 64.35 there's no connection to the 2019'er Exchange servers possible. Same issue: RESET from the Exchange Server with default TLS config. Some say 13.0 does the trick - seems not to be like that. Even changing the SecureRenogation did not work to get get the ServiceGroup up.


Link https://www.exchangelog.info/2020/02/netscaler-vs-exchange-2019-time-out.html shows how to downgrade tls security of the exchange servers. But that's not what we want to do. And 13.0 ist still Feature Release.


When will Citrix release a adc firmware build in maintenance release working with standard tls exchange 2019?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...