sslpoke | Tool for testing establishment of TLS connections in Java | TLS library

The most important thing to understand about this error is the meaning of this line:

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

SSL certificates work by establishing a certificate chain, or a hierarchy of trust. For example, if I go to https://www.google.com and look at their cert, this is what I see:

There is the google cert, which sits on their servers/CDN, then an intermediate cert which also sits on their servers/CDN, then a trusted root CA cert which is in the client keystore and is implicitly trusted. So when someone browses to google, b/c they have the root CA cert and have trusted it, the browser (client) will trust that the server is actually who they say they are and will establish a secure connection to the site.

So getting back to your error, whatever CA issued the server cert being used by RabbitMQ, the monitor is not recognizing it as trusted. To troubleshoot this error, here are the things to do:

• Look at the server cert and ensure it can be validated. openssl works well for this; run: openssl s_client -connect 127.0.0.1:15672 -showcerts and look at the cert chain.
• Validate the root CA is trusted by your java keystore. You can view these certs with the keystore tool: keytool -list -v -keystore -storepass . Ensure the cert listed above is in the keystore.

There are a couple other gotchas to watch out for:

• What keystore java is using is not always obvious. The jdk has a default keystore, and each app can use its own keystore, like you are doing above. Ensure you know what keystore is being used. Although it will add lots of logging, is can be helpful to add -Djavax.net.debug=all to the command line.
• Beware adding individual server certs to the keystore. This will work, until the server cert expires. Much better to depend on trusted CA certs, which are generally maintained at the platform level. Adding individual certs is generally considered an anti-pattern.

You can do this with very simple changes to the code, assuming you have a JDK or equivalent installed. Because TLS negotiates over a range of versions (until TLS1.3 and Java11, neither applicable here) there are two possibilities:

• you want to support or allow 1.2 (because the server requires it) but don't care about lower versions

• you want to require 1.2 only (and fail if the server supports lower)

For case 1 there are two choices:

You are handing the client a key store but in general you should be handing it a trust store as that is what tells the client which server certificates it trusts. You only give a key store when you are doing mutual authentication and the client needs to provide a certificate to the remote.

My first suggestion would be to set the transport.trustStoreLocation as defined in the client documentation.

If that doesn't work then it's time to break down and do some debugging of the SSL handshake.

Finally I found the answer.

1 - Of course the google/gmail certifcates were ok ;-) Step 1 was performing these kinds of checks. Trying to add the certificate CA by hand, etc. See above.

2 - Step 2 was checking whether the known 'SSLPoke' Java class Java class could get contact with the secure website.

3 - After checking all above checks, executing 'openssl' showed that my virus scanner email-shield blocked the traffic. Stopping this defence for some time was step 3.

4 - Then I got the 'not authenticated' error from Gmail. Allowing the 'gmail account accessable from weakly authenticated apps', that finally gave a correctly sent e-mail. This is an Google account security setting

You are using two different AMQP JMS client library dependencies on your project so I've no idea what's really going on, but my first guess is that you end up using the legacy 'qpid-amqp-1-0-client-jms' client which is not supported and definitely not going to work. I'd remove that and try to get things going with just the Qpid JMS 0.26.0 client library, although I believe there's some other URI options you might need as azure has some specific requirements in order to connect.