Forum Discussion

Steve_Lyons's avatar
Steve_Lyons
Ret. Employee
May 03, 2018

Server Side SSL Handshake Failures

Customer currently can connect to SharePoint directly over 443. When putting the BIG-IP in the mix, users are getting page cannot be displayed. After running a TCPDump, 3 way handshake occurs, client sends client hello and server sends RST. When running SSLDump, client sends cipher list and nothing in return from the server other than a RST. OpenSSL results below. Thoughts? Again, customer can connect directly to the webserver using the same url over 443 though through BIG-IP it fails. Customer has attempted to use different server ssl profiles to include default, secure, insecure compatible.

 

Current troubleshooting steps taken.

 

NETMON from web server: Syn > Syn/Ack > Ack > Client Hello > RST

 

SSLDump: Client Hello > RST

 

OpenSSL: openssl s_client -connect app.example.com:443 CONNECTED(00000003)

 

write:errno=104 no peer certificate available No client certificate CA names sent SSL handshake has read 0 bytes and written 249 bytes

New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE

 

Use of different Protocols: openssl s_client -connect -tls1_2 openssl s_client -connect -tls1_1 openssl s_client -connect -tls1 openssl s_client -connect -ssl3 openssl s_client -connect -ssl2

 

LTM Log: SSL Handshake failed Server > Self IP with status code 01260013

 

No Curl attempted to this point.

 

application delivery
LTM

6 Replies

Sort By
  • Surgeon's avatar
    Surgeon
    Ret. Employee
    May 03, 2018

    It Looks like you applied HTTP profile to the VIP and did not apply client and server ssl profiles. If so, then add server and client ssl profiles.

     

  • Steve_Lyons's avatar
    Steve_Lyons
    Ret. Employee
    May 03, 2018

    In order to determine which cipher suite and protocol was being used during a successful attempt to access the webpage by bypassing the BIG-IP, a capture was taken from the web server itself. This showed that TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 was the cipher suite used with TLS1.2. When looking at a TCPDump from the BIG-IP and then running a SSLDump against it, I see the client is sending a client hello using TLS1.1. My assumption was that negotiation would occur and they would establish a connection using 1.2 though we are not even getting to the point of negotiation because the server sends a RST immediately after the client hell. Will be testing ECDHE-RSA-AES256-GCM-SHA384:TLSv1_2 as the cipher string shortly to see the results.

     

  • Steve_Lyons's avatar
    Steve_Lyons
    Ret. Employee
    May 03, 2018

    ClientHello

     

    When a client first attempts to connect to an SSL server, it initiates the session by sending a ClientHello message to the server. The ClientHello message starts the SSL communication between the two systems. The ClientHello message contains some of the following components:

     

    Version: The version field contains the highest SSL version that the client supports.

     

  • Steve_Lyons's avatar
    Steve_Lyons
    Ret. Employee
    May 03, 2018

    Ok, just validated through SSLDump that TLS1.3 is being used along with the appropriate cipher suite that was accepted by the web server when bypassing the F5. However, still receiving Page Cannot Be Displayed when going through the BIG-IP.

     

  • Surgeon's avatar
    Surgeon
    Ret. Employee
    May 03, 2018

    If you are using IIS you will not get any SSL reset issue. One of the possible reasons, IIS requires for SNI being enabled. Can you check that part.

     

    It is very strange that your server requires TLS1.3. It is still DRAFT and BIG-IP does not support it yet. You need to switch to TLS1.2 and confirm if SNI is required.

     

  • Steve_Lyons's avatar
    Steve_Lyons
    Ret. Employee
    May 03, 2018

    I apologize, that was incorrectly stated, the server is still using tls1.2 though I had the ssldump versions on my mind with version 3.3=tls1.2. I will check SNI though. This is a strange issue all together since there are several more sharepoint servers using the same windows image, same ssl client profile with a wildcard cert and same serverssl profile though this particular pool is having issues establishing an ssl connection between BIG-IP and web server. Thank you again for your responses.