Forum Discussion

jfotopoulos_278's avatar
jfotopoulos_278
Icon for Nimbostratus rankNimbostratus
Nov 08, 2016
Solved

HTTPS/SSL failing on Windows clients

Hi,

we have recently purchased a BigIP VE (12.1) and are initially configuring it, but we are having a very strange problem where any browser from a mac or a linux client can successfully connect to our https site, but any client(chrome, firefox, IE) on any windows machine cannot. That has been tested on 3 different Windows versions (server 2012, windows 8 & windows 10).

We are trying to setup multiple sites on a single VS (exactly as in: Configuring a virtual server to serve multiple HTTPS sites using the TLS Server Name Indication feature)

Again, after this configuration was completed, everything was working correctly, except on windows systems. So, we tried the steps mentioned here: Troubleshooting SSL/TLS handshake failures The dump got all the way to the first application data packet and then was reset (TCP RST).

In the ltm log file we found the following message: 

Connection error: ssl_hs_rxhello:5771: unsupported version
So, after googling around, I fell onto this link ( ssl handshake issue, so I tried to enable sslv3, just to try it out (added DEFAULT:SSLv3 to the base ssl profile). But nothing changed.

The ssldump session gets a reset and doesn't show anything else that looks strange. Everything seams normal, except for a duplicate ACK and then a reset (in the wireshark session).

I have also tested the ssl communication with the qualys ssl checker, which also tests various browser versions on various builds. All good here, too.

Another thing that I should mention is that the certificates facing this issue are all from GoDaddy. Certificates from other CAs work flawlessly. But they only have issues on the BigIP. On nginx and apache there are no issues.

Thanks in advance for any replies

BIG-IP
client ssl profile
LTM
security
windows
  • jfotopoulos_278's avatar
    jfotopoulos_278
    Nov 11, 2016

    I have finally found out the problem. It had nothing to do with the ssl part. The whole issue was with a kernel sysctl option, net.ipv4.tcp_tw_recycle. This should have been set to "0" instead of "1".

     

    The strange thing about this that lead me to blame the ssl part was that problems only appeared with the backend system kernel version 4. One of our other backend servers is on kernel version 3.x.x and also had the same sysctl setting. We had no issues with this VS and the ssl certificate with the exact same setup. What is still troubling me is why did the problem only occur with windows clients and not with macosx or linux clients?

     

    After we solved the problem, we also found this related article:

     

    BIG-IP LTM and TMOS 11.5.4 where it is mentioned in the known issue section (542104). But, we have version 12.1.1, where in the 12.1.1 version of the same document page, BIG-IP LTM and TMOS 12.1.1 there was not any mention of it.

     

    It would be interesting to understand why the issue only comes up with windows clients. Does anyone have any ideas?

     

    Thanks

     

3 Replies

Sort By
  • Lee_Sutcliffe's avatar
    Lee_Sutcliffe
    Icon for Nacreous rankNacreous
    Nov 08, 2016

    It could be that the version of IE is using a cipher that is not supported by the cipher suite in the client-ssl profile.

     

    Check what ciphers your browser can use here: https://www.ssllabs.com/ssltest/viewMyClient.html

     

    Then compare the results with the output of the following in the CLI. This will display the ciphers supported in the cipher suite configured in the ssl profile. Change the string as required as you modify the ssl profile tmm --clientciphers 'DEFAULT:SSLv3'

     

  • boneyard's avatar
    boneyard
    Icon for MVP rankMVP
    Nov 08, 2016

    what if you take a step back and don't use SNI, but just one SSL profile, does it work then?

     

    is this a standard virtual server? do you re-encrypt to the pool?

     

  • jfotopoulos_278's avatar
    jfotopoulos_278
    Icon for Nimbostratus rankNimbostratus
    Nov 11, 2016

    I have finally found out the problem. It had nothing to do with the ssl part. The whole issue was with a kernel sysctl option, net.ipv4.tcp_tw_recycle. This should have been set to "0" instead of "1".

     

    The strange thing about this that lead me to blame the ssl part was that problems only appeared with the backend system kernel version 4. One of our other backend servers is on kernel version 3.x.x and also had the same sysctl setting. We had no issues with this VS and the ssl certificate with the exact same setup. What is still troubling me is why did the problem only occur with windows clients and not with macosx or linux clients?

     

    After we solved the problem, we also found this related article:

     

    BIG-IP LTM and TMOS 11.5.4 where it is mentioned in the known issue section (542104). But, we have version 12.1.1, where in the 12.1.1 version of the same document page, BIG-IP LTM and TMOS 12.1.1 there was not any mention of it.

     

    It would be interesting to understand why the issue only comes up with windows clients. Does anyone have any ideas?

     

    Thanks