Learn RabbitMQ - TLS/SSL Configuration & Encryption

#Introduction

So far all RabbitMQ connections have run in plaintext — without encryption. This may be acceptable on a secure internal network, but once the broker is accessed from outside the DC, from the cloud, or across regions, anyone on the network path can intercept the entire message contents. Your usernames, passwords, and business data flow as-is.

The solution is TLS/SSL: transport-layer encryption that protects AMQP (port 5671) and the Management UI (HTTPS). RabbitMQ has full TLS support, including two-way authentication with client certificates. This episode guides you from zero: creating your own Certificate Authority, issuing a server certificate, configuring TLS in rabbitmq.conf, up to best practices for certificate rotation and cipher suite selection.

#TLS Fundamentals

#Creating a CA and Certificates

For non-production environments, create your own CA with OpenSSL:

Create a CA and key

mkdir -p tls && cd tls
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
  -subj "/CN=MyTestCA" -out ca.pem

Then issue a certificate for the RabbitMQ hostname:

Create a server certificate

openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=rabbitmq.local" -out server.csr
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -days 825 -sha256 -out server.pem

The server certificate must use a name the client recognizes (hostname or IP), because the client will verify it.

#Assembling the Required Files

RabbitMQ needs three files: the CA (to verify clients), the server certificate, and the server private key:

Required TLS files

ca.pem        → sertifikat CA
server.pem    → sertifikat server
server.key    → private key server

#Enabling TLS

#AMQP over TLS

TLS listener configuration in rabbitmq.conf:

TLS listener in rabbitmq.conf

listeners.tcp.default = 5672
listeners.ssl.default = 5671
ssl_options.cacertfile = /etc/rabbitmq/tls/ca.pem
ssl_options.certfile = /etc/rabbitmq/tls/server.pem
ssl_options.keyfile = /etc/rabbitmq/tls/server.key
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = false

The configuration above opens port 5671 for AMQP over TLS with peer verification. Clients connect using the amqps scheme:

#Management UI over HTTPS and Verification Modes

The Management UI can be encrypted by adding an HTTPS listener port in rabbitmq.conf (management.tcp.port stays at 15672, management.ssl.port = 15671). Two verification modes are available: verify_peer (verifies the client certificate) and verify_none (no verification, encryption only). For full client authentication, set fail_if_no_peer_cert = true and combine it with the rabbitmq_auth_mechanism_ssl plugin from episode 15.

#Cluster Inter-Node Encryption

Nodes in a cluster can also communicate over TLS by setting ssl_options on the distribution listener. Keep in mind: inter-node encryption adds CPU overhead — consider whether the internal cluster network is trusted enough. Before opening TLS connections, verify that the SSL port is really listening with rabbitmq-diagnostics listeners.

#TLS Best Practices

#Certificate Rotation

Certificates must be rotated before they expire. Prepare a procedure: issue a new certificate, reload the configuration or restart in a rolling fashion, and verify with a test connection before the old certificate expires. In a cluster, rotate per node to avoid downtime.

#Cipher Suites and TLS Versions

Limit the cipher suites in use and disable outdated TLS versions:

Limit cipher suites and TLS versions

ssl_options.versions.1 = tlsv1.3
ssl_options.versions.2 = tlsv1.2
ssl_options.ciphers.1 = TLS_AES_256_GCM_SHA384
ssl_options.ciphers.2 = ECDHE-RSA-AES256-GCM-SHA384
ssl_options.honor_cipher_order = true

The configuration above only allows TLS 1.2 and 1.3 with modern ciphers. Avoid TLS 1.0/1.1, which are no longer secure.

#TLS Troubleshooting

When a TLS connection fails, common causes: the hostname doesn't match the certificate's CN, the CA is not trusted by the client, or the key doesn't match the certificate. Verify file consistency with:

Check certificate and key match

openssl x509 -noout -modulus -in server.pem | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5

If the two hashes above differ, the private key doesn't match the certificate — the most common cause of failed handshakes.

Warning

Never disable certificate verification in production clients just to shorten setup time. An amqps scheme with verification turned off gives the impression of security when there's actually no protection against man-in-the-middle attacks.

#Conclusion

In episode 17 you created a CA and server certificates with OpenSSL, enabled AMQP over TLS on port 5671, set up peer verification and client certificate authentication, and applied certificate rotation, cipher suite, and TLS troubleshooting practices.

Key takeaways:

TLS protects AMQP (port 5671) and the Management UI (HTTPS).
Clients connect with the amqps scheme for encrypted connections.
verify_peer verifies the client certificate; verify_none only encrypts.
Certificates must be rotated before they expire.
Limit cipher suites and only allow TLS 1.2 and above.
The client hostname must match the server certificate's CN.
Key and certificate mismatch is a common cause of failed handshakes.

In the next episode we will set up network configuration and firewalls — all the ports RabbitMQ uses, bind address and interface configuration, IPv4 vs IPv6, and firewall rules for single nodes and clusters in the cloud. This determines who can reach your broker!