API call failure from IBM ACE server to Elasticsearch

ECE version 2.4 on-premise:
I have a user that is trying to send IBM ACE logs to Elasticsearch with an API call. This call was working as of Feb 10, 2020 and then just stopped. The API call works from their local computers when testing but when its run from the IBM servers it starts throwing errors. Attached are portions of the error log that I’ve been sent. If more is needed I will do what I can to provide more.

(0x03000000:NameValue):Text = 'A Web Service request has detected a SOCKET error whilst invoking a web service located at host &1, on port &2, on path &3.' (CHARACTER)
(0x03000000:NameValue):Text = abc.gov' (CHARACTER)        )
(0x03000000:NameValue):Text = '9243' (CHARACTER)
(0x03000000:NameValue):Text = '/acestats/_doc' (CHARACTER)
(0x03000000:NameValue):Text     = 'An error occurred whilst performing an SSL socket operation' (CHARACTER)
(0x03000000:NameValue):Text = 'javax.net.ssl.SSLException: Received fatal alert: protocol_version' (CHARACTER)

Here are the relevant notes on configuring the HTTPRequest Node (what we use to call Elastic) in terms of SSL:

On the SSL tab, if you want to use HTTP over SSL (HTTPS) requests, set the values for HTTPS requests:
A. Specify the Protocol property that you want to use to make the request.
Both ends of an SSL connection must agree on the protocol to use. Therefore, the selected protocol must be one that the remote server can accept. The following options are available:

  • SSL. This option is the default. This option tries to connect by using the TLS protocol first, but enables the handshake to fall back to the SSLv2 protocol where the SSLv2 protocol is supported by the underlying JSSE provider.
  • SSLv3. This option tries to connect with the SSLv3 protocol only. Fallback to SSLv2 is not possible.
  • TLS. This option tries to connect with the TLS protocol only. Fallback to SSLv3 or SSLv2 is not possible.

B. Set the Allowed SSL ciphers property.
Use this setting to specify a single cipher (such as SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) or a list of ciphers that are the only ones that are used by the connection. This set of ciphers must include one or more that are accepted by the remote server. A comma is used as a separator between the ciphers. The default value is an empty string, which enables the node to use any, or all, of the available ciphers during the SSL connection handshake. This method gives the greatest scope for making a successful SSL connection.

C. Use the SSLKeyAlias property to specify a SSL authentication alias for the client-side of an HTTP connection.
The server checks an access control list for this client-side key. The key alias that identifies the key in the integration node or integration server keystore that is to be used for the SSL connection. Set this optional property if your keystore contains more than one key. The default value "" (or none), means that an SSL key alias is not used. Any other string value identifies the alias.

I had a quick chat with the network team, and they weren't aware of any known issues that might be causing this (unless your proxy cert has expired and when you run locally you have your client set to ignore that ... that didn't seem likely from the info presented above)

The suggestion was to raise a support ticket

Note some (client-side) reasons for the error you report are discussed here: https://stackoverflow.com/questions/16541627/javax-net-ssl-sslexception-received-fatal-alert-protocol-version

Did you recently upgrade to a different version of Java or something like that?

I will look through the stackoverflow thread. I don't believe that I've upgraded java on our end at all but will see if anything has been updated on the other end.

I did put a support ticket in as well. I appreciate the help and ill let our other team know about your response.

I did a bit more digging:

Here's our supported versions/ciphers:

    min_tls_version: TLSv1.2

I think that error corresponds to a discrepancy in min_tls_version

Note that the TLSv1.2+ requirement only came from 2.4+ ... so if you upgraded and your client only supported TLS v1.1 (eg the default for Java 7 I believe) then you would expect to start seeing the error

My guess would be (regardless of what happened when) that your client at this point is trying to connect using TLSv1 and that is the cause of the error

I'd try changing your SSL mode in the UI you showed to SSL or SSLv3

Bonus documentation! https://www.elastic.co/guide/en/cloud-enterprise/current/ece-configure-tls-version.html

Nice! So it looks like we need to figure out which version of Java is currently being used with IBM ACE and with that check which version of TLS is being utilized by the application. Then adjust the TLS protocol if needed to TLSv1.2 at a minimum. A java upgrade might be in order as well.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.