TLS - SSL-Konfiguration

Transport-Verschlüsselung

RabbitMQ lauscht ohne explizite Konfiguration auf unverschlüsselte Verbindungen auf Port 5672 und bietet eine Authentifizierung mit Benutzername und Passwort an. Um RabbitMQ zur Nutzung von TLS zur Transferverschlüsselung zu bewegen, müssen der passende SSL-Port aktiviert und Zertifikat und Schlüssel hinterlegt werden. Zusätzlich sollte der unverschlüsselte Zugriff untersagt werden.

Eine entsprechende Konfiguration (rabbitmq.conf) sieht wie folgt aus:

# RabbitMQ broker section
# ======================================
## Networking
## ====================
listeners.ssl.default            = 5671
listeners.tcp                    = none

## TLS configuration.
## ====================
ssl_options.certfile             =
/etc/rabbitmq/rabbitmq-chain.pem
ssl_options.keyfile              = /etc/rabbitmq/rabbitmq.key
ssl_options.verify               = verify_peer

Im Vergleich dazu im älteren Erlang-Format (rabbitmq.config):

[{rabbit, [
       {ssl_listeners, [5671]},
       {tcp_listeners, []},
       {ssl_options, [
         {certfile,"/etc/rabbitmq/rabbitmq-chain.pem"},
         {keyfile,"/etc/rabbitmq/rabbitmq.key"},
         {verify,verify_peer}
        ]}
]}].

Zertifikatsbasierte Authentifizierung (Zwei-Wege-SSL-Verbindung)

Um die Authentifizierung am RabbitMQ-Server anstatt mit Benutzername/Passwort mit einem X509-Zertifikat zu bewerkstelligen, muss auf Seiten der RabbitMQ sowohl das Plugin rabbitmq_auth_mechanism_ssl aktiviert, als auch die Konfiguration wie folgt ergänzt werden:

# RabbitMQ broker section
# ======================================
## Networking
## ====================
auth_mechanisms.1                = PLAIN
auth_mechanisms.3                = EXTERNAL

## TLS configuration.
## ====================
ssl_options.cacertfile           = /etc/rabbitmq/cacert.pem
ssl_options.fail_if_no_peer_cert = false
ssl_cert_login_from              = common_name

Im Vergleich dazu im älteren Erlang-Format (rabbitmq.config):

[{rabbit, [
  ...
       {auth_mechanisms, ['PLAIN','EXTERNAL']},
       {ssl_options, [
          ...
         {cacertfile,"/etc/rabbitmq/cacert.pem"},
         {fail_if_no_peer_cert,false}
        ]},
       {ssl_cert_login_from, common_name}
]}].

Die zu verwendende cacert.pem ergibt sich aus dem Schritt Generierung Client-Zertifikat.

Generierung Client-Zertifikat

Da RabbitMQ sich sehr wählerisch in Bezug auf Client-Zertifikate verhält, sollte die offizielle Anleitung für die Generierung eines solchen herangezogen werden. Die erzeugte client/keycert.p12 findet dann Anwendung im Client, cacert.pem wird als serverseitiger TrustStore benötigt.

Generierung SecureConnector-TrustStore

Für den Aufbau einer verschlüsselten Verbindung zum RabbitMQ-Server benötigt der SecureConnector einen TrustStore im Java-Keystore-Format, der die Authentizität des Server-Zertifikats sicherstellt. Bei einem offiziellen Zertifikat einer Authentifizierungsstelle, kann als Basis die cacerts der verwendeten JRE herangezogen werden (jre/lib/security/cacerts, Standardpasswort: changeit). Dort muss in der Regel noch das Endzertifikat oder eine Chain-Datei des Zertifikats hinzugefügt werden:

keytool -import -keystore cacerts -file /server-certificate.pem -alias RabbitMQ

Alternativ kann ein neuer Keystore angelegt werden, der die gesamte Server CA-Kette enthält, und dieser dem Fachverfahren als Trust-Store zur Verfügung gestellt werden.

Beispiel-Konfigurationen

Im Folgenden finden Sie mögliche Beispiel Konfigurationen, die Sie als Referenz heranziehen können.

RabbitMQ

# RabbitMQ broker section
# ======================================
## Networking
## ====================
auth_mechanisms.1                = PLAIN
auth_mechanisms.3                = EXTERNAL
listeners.ssl.default            = 5671
listeners.tcp                    = none

## TLS configuration.
## ====================
ssl_options.cacertfile           = /etc/rabbitmq/cacert.pem
ssl_options.certfile             =
/etc/rabbitmq/rabbitmq-chain.pem
ssl_options.keyfile              = /etc/rabbitmq/rabbitmq.key
ssl_options.verify               = verify_peer
ssl_options.fail_if_no_peer_cert = false
ssl_cert_login_from              = common_name

Im Vergleich dazu im älteren Erlang-Format (rabbitmq.config):

[{rabbit, [
       {tcp_listeners, []},
       {auth_mechanisms, ['PLAIN','EXTERNAL']},
       {ssl_listeners, [5671]},
       {ssl_options, [
         {cacertfile,"/etc/rabbitmq/cacert.pem"},
         {certfile,"/etc/rabbitmq/rabbitmq-chain.pem"},
         {keyfile,"/etc/rabbitmq/rabbitmq.key"},
         {verify,verify_peer},
         {fail_if_no_peer_cert,false}
        ]},
       {ssl_cert_login_from, common_name}
]}].

SecureConnector

Für die Zwei-Wege-SSLVerbindung des SecureConnectors muss das Rechenzentrum dem Fachverfahren einen TrustStore zur Verfügung stellen, wie er im Punkt Generierung SecureConnector-TrustStore beschrieben ist. Dieser muss dann, in Verbindung mit dem Client-Zertifikat, in die application.properties-Datei des Fachverfahrens integriert werden:

spring.rabbitmq.host=<rz-host>
spring.rabbitmq.port=5671
spring.rabbitmq.ssl.enabled=true
spring.rabbitmq.ssl.key-store=file:/pfad/zum/keycert.p12
spring.rabbitmq.ssl.key-store-password=<keystore passwort>
spring.rabbitmq.ssl.trust-store=file:/pfad/zum/truststore
spring.rabbitmq.ssl.trust-store-password=<ttruststore
passwort>
spring.rabbitmq.virtual-host=/12345678-1234

fs.messaging.queue=ikfz