Forum Discussion

Danny_Arroyo's avatar
Sep 27, 2016

HTTPS Health Monitor Not working

We are running v11.4.1 Build 685 (we will be upgrading shortly) on our LTM 2000 series Bigip. I am having a problem getting an HTTPS Monitor to work on a Java Web Site that is hosted on our LTM.

I ran curl on the java site so I can see my options for the receive string. This is the curl command:

curl -vk https://website.mycompany.com/webnow/index.jsp

A part of the curl result is listed below. I want to use "Perceptive Content" as a receive string:

` Perceptive Content

`

Now when I created the HTTPS monitor, I tried to use the Standard send string ('GET /\r\n') but that doesn't work. My guess is because this site redirects to a CAS server for authentication so the page is not built until after authentication. However the TITLE of the TAB where the website was initiated has the title specified by the web server. Therefore I want to use the TITLE of the TAB as a receive string.

I tried the following HTTPS Monitor send strings, but both of them disable the nodes in the pool: (The receive string is set to "Perceptive" - See Screenshot)

  1. GET /webnow/index.jsp/ HTTP/1.1\r\nHost: website.mycompany.com\r\nConnection: Close\r\n\r\n
  2. GET /webnow/index.jsp HTTP/1.1\r\nConnection: Close\r\nHost: website.mycompany.com\r\n\r\n\r\n

I've tried several different iterations of the send string without any success. Can anyone tell me what I'm doing wrong?

6 Replies

  • Just for closure.

     

    F5 technical support found the issue. It was that I had the pool members configured to talk over port 80, not port 443. Although I was using the https_443 monitor on the pool (which worked because port 443 is open on the members), the members were not configured for port 443 in the pool. That was what I did wrong.

     

    Thanks again for all your help, Boneyard.

     

    • boneyard's avatar
      boneyard
      Icon for MVP rankMVP

      you are welcome, great you found a solution and posted it back.

       

  • F5 did change cipher behavior in v11.4. One thing that bit us after upgrading from v11.2 to v11.4.1 was TLS negotiation. The new code attempts to use TLS1.2 first, whereas v11.2 attempted TLS1.0 first. This increased security posture broke some of our applications that didn't support TLS1.2.

     

    • Danny_Arroyo's avatar
      Danny_Arroyo
      Icon for Cirrus rankCirrus

      I'm sorry, but I don't understand your answer. Are you saying that I should not make an HTTPS monitor? How should I change my HTTPS monitor so that it works?

       

      Thanks.

       

  • your curl output doesn't show Perceptive to be returned, are you sure it is there?

     

    as for the reply from Samir, he suggests that it might be your server doesn't like TLS1.2, but that might not be the issue.

     

    i would start testing with openssl, do a

     

    openssl s_client -connect [serverip]:[port]

     

    then create the request like you did in your two examples, it should be the GET without a / at the end and ending with HTTP/1.1

     

    then the Host and finally the connection close.

     

    see how the server responds to that. put the output here for extra eyes.

     

  • Change you cipher string from:

     

    DEFAULT:+SHA:+3DES:+kEDH

     

    to

     

    ALL

     

    PS: I take no responsibility for what this may do to your security auditing team's blood pressure...

     

    //Jan