Did anyone encounter such issue using https health monitor where suddenly it communicates with real server using TLSv1 instead of TLSv2?
I have a pair of F5 active-standby. All the while I was using https health monitor and F5 sent query using TLSv1.2. In fact the standby unit is still communicating using TLSv1.2. However the active unit suddenly use TLSv1 which causes the pool member to become inactive.
Hope anyone can advise.
Thank you in advance.
Have you read this thread : https://devcentral.f5.com/s/question/0D51T00007EM6ML/f5-server-ssl-profile-using-tls-10-instead-of-t...
Are you in the same configuration .NET app using SNI ?
hi Lidev, actually we found out it is a bug. Bug ID 739963. The only problem is we need to find out why the sslhandshake failed that trigger this bug.
F5 has no answer as per the KB
HTTPS monitors mark a TLS v1.2-configured pool member down and never mark it back up again, even if the pool member is up. The monitor works normally until the SSL handshake fails for any reason. After the handshake fails, the monitor falls back to TLS v1.1, which the pool members reject, and the node remains marked down.
Once the handshake fails, the monitor remains in fallback mode and sends TLS v1.0 or TLS v1.1 requests to the pool member. The pool member remains marked down.
This might occur when the following conditions are met:
-- Using HTTPS monitors.
-- Pool members are configured to use TLS v1.2 only.
To restore the state of the member, remove it and add it back to the pool.
Like I said its bug. See above I posted.
the health monitor was working fine for the last several months. It communicate to server via tls1.2 and something happen we dont know what causes the sslhandshake to break and then F5 fallback to tlsv1...and since server dont support it becomes inactive on F5 end. F5 got stuck on tls1v.
I had similar issue, it was bug so check the F5 bug tracker. Here i what I found (the bugs were my issue):