Ich führe RabbitMQ 3.6.1 / Erlang 18.3 aus und stelle fest, dass ich mit dem Broker, der den Spring AMQP 1.5.4.RELEASE Java-Client verwendet, keine TLSv1- oder TLSv1.1-Sitzung einrichten kann. Ich bin jedoch in der Lage, eine TLSv1.2-Sitzung mit dem Broker einzurichten. Mein RabbitMQ-Broker ist so konfiguriert, dass er alle drei von tlsv1, tlsv1.1 und tlsv1.2 unterstützt. Ich verwende Java 1.8.0_77-b03 unter OS X.
Hier ist meine RabbitMQ-Konfiguration:
Erlang auf dem Broker meldet SSL-Versionen
%Vor%Dies ist der Fehler, den RabbitMQ bei einem Fehler protokolliert:
%Vor%Ich habe tcpdump verwendet, um den Verkehr auf dem sicheren Port 5671 während des TLS-Setups zu erkennen. Hier ist tsharks Formatierung dieser Daten:
%Vor%Hier ist der Spring-Verbindungsfehler:
%Vor%Mein RabbitMQ-Broker ist so konfiguriert, dass er tlsv1, tlsv1.1 und tlsv1.2 aushandelt. Warum schlägt das TLS-Setup für tlsv1 und tlsv1.1 fehl, wenn der Broker dies unterstützen sollte? Derselbe Java-Client kann TLSv1 mit einem RabbitMQ 3.3.1 / Erlang R16B02-Broker aushandeln.
Danke.
Es gab einige Regressionen in der Erlang ssl -Anwendung in der 18.3.x-Serie. Einer von ihnen verursacht, was Sie sehen: Clients während Handshake abgelehnt, mit insufficient security auf der Serverseite angemeldet. Wenn ich mich richtig erinnere, erschien dies in Patch 18.3.3 und wurde in 18.3.4 behoben. Dies ist kein Problem vom Client.
Es gibt eine Regression in 18.3.2, behoben in 18.3.3, die verhindert hat, dass RabbitMQ überhaupt gestartet wurde (aufgrund einer Änderung in der Repräsentation von Chiffre-Suites).
Daher wird empfohlen, auf 18.3 (die erste Version) zu bleiben oder auf 19.x zu aktualisieren.