Enable TLS for RabbitMQ

The fix/etc/rabbitmq/rabbitmq.conf

listeners.ssl.default = 5671
listeners.tcp = none                         # no plaintext AMQP

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
ssl_options.versions.1 = tlsv1.3
ssl_options.versions.2 = tlsv1.2

sudo systemctl restart rabbitmq-server

Why it matters

Without TLS, RabbitMQ sends the AMQP authentication and every message body in cleartext. Message brokers carry exactly the data you’d least like on the wire — job payloads, user events, and frequently credentials and tokens inside those messages. Anyone on the network path reads all of it.

RabbitMQ’s own auth is undermined by plaintext transport too: the username and password are sent in the clear on connect, so a hardened user model is only as private as the link underneath it.

Enabling TLS is not requiring it

The now-familiar trap, and RabbitMQ makes it easy to fall into: adding listeners.ssl.default = 5671 adds a TLS listener. It does not remove the plaintext one on 5672. A broker with both is not protected — a client connects to 5672 in the clear and is accepted.

listeners.tcp = none is what closes it. Do that once every client speaks TLS, and confirm with rabbitmq-diagnostics listeners rather than assuming — see network listeners.

The verify_peer settings, precisely

RabbitMQ’s TLS options are frequently misconfigured because two settings interact in a way that isn’t obvious:

Setting	Effect
verify = verify_none	Encrypt, but don’t check the client’s certificate
verify = verify_peer	Check the client certificate if one is presented
fail_if_no_peer_cert = true	Require a client certificate — reject connections without one

The combination that means “mutual TLS, client certs required” is verify = verify_peer and fail_if_no_peer_cert = true. verify_peer alone does not require a client cert — it only validates one if the client happens to send it, so a client with no certificate still connects. That surprises people who set verify_peer believing they’d mandated client certificates.

If you only want server-authenticated TLS (encryption, server identity verified by the client, but no client certs), verify_peer with fail_if_no_peer_cert = false is correct and far easier to operate. Mutual TLS is stronger but means issuing and rotating a certificate per client.

The client side matters too: a client must be configured to verify the server certificate (verify_peer on its end, with the CA), or it encrypts without checking who it’s talking to — the same sslmode=require vs verify-full distinction as Postgres.

The key file permissions are enforced

RabbitMQ refuses to start if keyfile is too permissive:

sudo chown rabbitmq:rabbitmq /etc/rabbitmq/tls/server.key
sudo chmod 400 /etc/rabbitmq/tls/server.key

A key readable by other users is both a startup failure and a real exposure.

Verify it worked

Confirm the TLS listener is up and plaintext is gone:

rabbitmq-diagnostics listeners

Want amqp/ssl on 5671 and no plain amqp line.

Prove a plaintext client is refused:

nc -zv -w5 localhost 5672 2>&1 | tail -1        # expect refused if listeners.tcp = none

Check the certificate the broker presents, independent of any client:

openssl s_client -connect localhost:5671 -starttls... </dev/null 2>/dev/null | \
  openssl x509 -noout -subject -enddate 2>/dev/null || \
  openssl s_client -connect localhost:5671 </dev/null 2>&1 | grep -E 'subject=|Verify'

RabbitMQ has a built-in TLS health check:

rabbitmq-diagnostics tls_versions
rabbitmq-diagnostics cipher_suites --format openssl

Confirm fail_if_no_peer_cert is what you intended:

rabbitmqctl environment | grep -iE 'fail_if_no_peer_cert|verify'

If you meant to require client certs, fail_if_no_peer_cert must be true — and test it: a client with no cert should be rejected, not merely encrypted.

Before you apply this

listeners.tcp = none disconnects every plaintext client at once, and RabbitMQ’s connection-refused gives the client no hint that TLS is the answer.

Stage it: enable the TLS listener alongside plaintext, migrate clients to amqps:// with the CA configured, confirm each with rabbitmqctl list_connections, then set listeners.tcp = none.

fail_if_no_peer_cert = true is the sharpest edge. Turn it on and every client without a valid client certificate is rejected — which, if you haven’t issued client certs yet, is all of them. Only enable it once every client has its certificate and you’ve tested the connection. If you’re not running mutual TLS, leave it false; turning it on “for extra security” without issuing client certs is an instant outage.

Certificate expiry disconnects clients and, if you use TLS for clustering, breaks the cluster. RabbitMQ can also do TLS on the distribution port; if you’ve enabled that, an expired cert partitions the cluster, not just client connections. Monitor expiry — the -enddate check above — rather than discovering it as a cluster-wide outage.

Reload won’t apply TLS changes; this needs a restart, which drops all connections. Schedule it.

Related

• Restrict network listeners — disabling plaintext AMQP.
• Virtual host permissions — the credentials TLS protects.