SSL handshake errors

Great, so first step is to turn it off at the server. If you can't do that, try this simple iRule to remove it from responses:

when HTTP_RESPONSE {    
    if { [HTTP::header exists "Strict-Transport-Security" } {        
        HTTP::header remove "Strict-Transport-Security"
    }
}    

If that does the trick, then you just need to wait that 500 seconds for the cache to timeout and then try again.

From header it seems like server is sending it but I haven't configured it on bigip.

< Strict-Transport-Security: max-age=500

Not clients. Servers. If you're seeing this header at the client, then someone is sending it.

No its not configured in an iRule and No clients are not configured to send it.

Hit send too soon. This isn't enabled by default in a v12 HTTP profile, so do you have an iRule sending it? Can you tell if the application server is configured to send it?

Look at the HTTP profile in the GUI. This is v12?

Not sure about clients being able to do that and cause handshake errors?

The point is that a modern browser will fail on trust issues if this header is present.

I don't see it

[root@xxx:Active:In Sync] config grep hsts bigip.conf [root@xxx:Active:In Sync] config

Not sure about clients being able to do that and cause handshake errors?

If this is v12 you should definitely see an hsts setting in HTTP profile. In either case, in the HTTP profile assigned to this VIP, do you see the HTTP Strict Transport Security option (at the botton of the profile)? And if so is it enabled? If it's not enabled, is it possible that the application itself is sending the HSTS header?

Kevin,

I should see this in my bigip.conf profile:

    hsts {
        mode enabled
    }
    

but I am not seeing it there. Search for hsts in bigip.conf didn't find anything. Not sure what this means.

Naresh

Yes, this header indicates that you're using HSTS. Basically, that header tells the browser a few things:

1. For all subsequent requests to this URL, always connect via HTTPS (regardless of the URLs presented to the browser)

    

2. If for any reason the server's certificate cannot be validated, fail completely. In other words you don't get the option to bypass/ignore the error. It just fails.

    

It's very likely working in cURL because cURL doesn't understand HSTS. The max-age directive is in seconds, and that's how long the browser caches this information. Thankfully you didn't specify the usual 1 week, because it's very difficult to clear that cache. So at the very least you need to uncheck this value in the HTTP profile and wait 500 seconds to allow the browser to forget the setting. You may notice afterwards that the browser will prompt you to ignore the untrusted cert.