Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

SSL Cipher error in ltm logfile "Cipher XX:Y negotiated is not configured in profile <sslprofilename>"

I recently moved an HTTPS Virtual Server from an old LTM (running 9.3.1) to a new pair of load balancers running 11.4.1. This particular Virtual Server is using both a client SSL profile and a server SSL profile, pointing at a pool with a single node. Everything seems to be working with my various browser testing. However, I'm seeing log lines in /var/log/ltm such as the following:

Nov 7 08:10:33 bigip7 err tmm4[12863]: 01260014:3: Cipher 16:2 negotiated is not configured in profile /Common/MyClientSSLProfile.

Nov 7 08:21:44 bigip7 err tmm3[12863]: 01260014:3: Cipher 16:2 negotiated is not configured in profile /Common/MyServerSSLProfile.

Both of the above SSL Profiles utilize the "DEFAULT" cipher list. So, my assumption is that some clients are hitting this Virtual Server and are presenting a cipher that the DEFAULT cipher list doesn't include.

Can anyone decode what the "Cipher 16:2" (there are others... "Cipher 4:3", "Cipher 16:3", "Cipher 4:2" etc.) notation means - is it specific to the lines you see when you issue "tmm -clientciphers 'DEFAULT'" or "tmm -serverciphers 'DEFAULT'"?

I'm not sure that anything is really wrong here, but I am concerned that we might be trashing some SSL connections (doing a tcpdump of the traffic, and correlating times when the above /var/log/ltm errors get logged, then looking up the source IP address and correlating the timestamp to the Apache logfiles shows me most of these hits are to the webserver and doing a "GET /") - clearly not all SSL transactions are throwing the /var/log/ltm errors - just some.

Thanks for any insight anyone may have.

  • Joe
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I don't believe that cipher message is going to map to a specific cipher and I've only ever seen it when the Proxy SSL is configured. Is that a feature you've enabled?

Enabling debug logging for SSL might help, just remember to set it back when done.

tmsh modify sys db log.ssl.level value debug

tmsh modify sys db log.ssl.level value warning

Just a guess; Proxy SSL is enabled and the backend server is using a cipher which isn't in BIG-IP's DEFAULT cipher list. Just some additional background:

http://support.f5.com/kb/en-us/solutions/public/13000/300/sol13389.html

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I had a similar error that I was troubleshooting, specifically the error was:

Cipher 9d:5 negotiated is not configured in profile /Common/XXXXXXXX

As Kevin K mentioned above, the cipher that was being selected by the Client and Server in my Proxy SSL connection was not available to the F5. This was tricky to track down as I could not find a reference to 9d:5 anywhere.

A Wireshark capture helped me to identify the cipher selected, below is the snip:

Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 4487
    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Length: 81
        Version: TLS 1.2 (0x0303)
        Random
        Session ID Length: 32
        Session ID: 50220000c0b5570bb4d67cbf40ce8e742bbda00f380a0d9f...
        Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
        Compression Method: null (0)

My theory was a correlation between "9d" in the ltm log and cipher suite 0x009d. A few quick searches didn't reveal much initially, until I removed the leading 0 in front of the 9d and saw on the SOL13163: SSL ciphers supported on BIG-IP platforms (11.x - 12.x) page that "9d" corresponds to "AES256-GCM-SHA384 (0x9d)"

Once I had that I was able to look at what cipher suites were available to my profiles based on the current configuration, which was "DEFAULT".

tmm -serverciphers 'DEFAULT'

Showed me that cipher suite "AES256-GCM-SHA384 (0x9d)" was not an option. However

tmm -serverciphers 'NATIVE'

did show that cipher suite as an option. I modified my ciphers in the custom clientssl and serverssl profiles to use NATIVE instead of DEFAULT and the errors went away because the F5 could now read the traffic.

I realize this is a long explanation on an older post, but I'm hoping to share with anyone else how I arrived at this (the process) so that if someone else ends up here they'll have the steps to follow.

1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Thanks for your reply, and that link to the KB article.

I do have "Proxy SSL" enabled on both SSL profiles - this is kind of new to me, though- on the 9.3.1 platform, this didn't exist, but it seems like the only way I could get the same functionality on 11.4.1. Frankly, this is a simple setup:

2 backend Web servers A and B. There's a single virtual server for port 80 requests and a single virtual server for port 443 requests. There's an iRule in place on the port 80 VS which simply does "when http request, if URI = (a number ofthings) send it to node A, otherwise send it to B". The port 443 VS has a pool associated with it which only includes Server B - all SSL traffic is sent to Server B.

While I have things set up to do x-forwarded-for on the SSL Virtual Server I don't even know that I care to have that functionality - which raises the question of why I'm doing Proxy SSL at all. The "Server B" webserver has the SSL certificate, key, root CA, intermediate certificates just as the F5 does; maybe I'm making this more complicated, and should configure the SSL Virtual server to simply connect the client directly to Server B for all SSL traffic. I'm just not sure I know how to do that - seems like Proxy SSL is the only way I could get it to work...

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

You're welcome. On the surface it doesn't appear you really need the Proxy SSL feature. I would consider using Proxy SSL for instances where you need to leverage an optimization feature like cookies, iRules, compression, etc. Another benefit is passing some larger object like client SSL certificate to the backend server. You could most likely either terminate the Certificate / Key on the BIG-IP or simply pass the 443 straight through.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Yeah, I want to pass the traffic straight through (for what are likely dumb reasons, I can't terminate SSL on the BIG-IP due to the way Apache is configured on Server B - it's a server I don't run, is old, and needs to do its own SSL stuff, apparently). I guess I'll play with other configurations that don't use the Proxy SSL feature and see where I end up. Thanks again. - Joe

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

A simple Performance Layer 4 is probably all you need to pass the TCP/443 traffic along.

http://support.f5.com/kb/en-us/solutions/public/14000/100/sol14163

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi ,

I am too getting these messages like below. Cipher 4:3 negotiated is not configured in profile /scms_partition/CRM-.app/CRM.

I am not sure why this , Log level -err,

0