Java 8 SSL handshake failure from amqp client to rabbitmq server

0
votes

Please read the context from previous post. That issue is resolved. Re-creating the queue and re-connecting to rabbitMQ

Now, I am trying to setup ssl enabled connection between rabbitmq server and rabbit client. I am using spring boot with spring cloud bus. Without SSL things work perfect.

  • Used this to run the java rabbit client.

> Versions

Java 1.8

spring-cloud-starter-bus-amqp => 1.3.1.RELEASE

Spring boot parent => 1.5.9.RELEASE

sudo java -Djavax.net.debug=all -Dhttps.protocols=TLSv1 -jar target/rabbit-client-0.0.1-SNAPSHOT.jar

tried -Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as well

  • I used below command and it works with result as Verified [ok]. This tells me that rabbitmq server is configured correctly with certs.
openssl s_client -connect my.rabbitmq.com:5671 -cert nonprod.crt -key nonprod.key -CAfile nonprod-chain.crt -tls1 -prexit
  • I can visit rabbitmq managemnet portal from chrome browser and it trusts the cert since I added it trusted in keychain.
  • I have added the cert and CA cert to java key store and trusted it.
  • Amqp client cannot establish the connection and fails with SSL enabled.

Link to view error and debug logs

See below failure.

This is what I believe can be issue but not sure.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLSv1.1 is appearing in list of unsupported cipher and may be rabbitmq server is asking for that as encryption suite.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 unsupported ????

1
javasslrabbitmqsslhandshakeexceptionspring-cloud-bus
Please: Logs in a screenshot are bad - not searchable not good to read and the important part is usually truncated. Please edit your post and replace the screenshot with the text - a console can be copied in seconds... – Robert
Give the exact Java version of your client. – Eugène Adell
Java 1.8, spring-cloud-starter-bus-amqp=> 1.3.1.RELEASE, Spring boot parent => 1.5.9.RELEASE – turbocoder
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is unsupported in TLSv1.1 and also TLSv1(.0) because the TLS specifications require that. All GCM ciphersuites, in fact all AEAD ciphersuites, only work in 1.2 or higher. Your log shows the error happening on CCS/Finished, long after version 1.2 and that suite were successfully negotiated. The server requested the client do authentication, aka send a certificate, and it didn't, which is sufficient reason for many servers to abort the handshake. Either change the server not to request auth, or change the client to supply it, like you did with openssl. – dave_thompson_085
Thanks @dave_thompson_085. I am not sure why the certificate is not found as i have added it in the keystore and CA authority is same as used in the server. – turbocoder

1 Answers

0
votes

The issue was Erlang OTP was rejecting the certificate as bad certificate due to invalid Key Usage fields. follow these guidelines for creating the certs. http://erlang.org/documentation/doc-5.7.4/lib/ssl-3.10.7/doc/html/pkix_certs.html