#Secure Client Connections with TLS

Use TLS when producers, consumers, automation, or administrators connect to RabbitMQ over an untrusted network, through an external NodePort or LoadBalancer, or across clusters. TLS protects AMQP traffic and the management HTTP API from clear-text transmission.

This guide covers RabbitMQ listener TLS for client access. It does not replace user, virtual host, or permission controls. Configure both TLS and least-privilege RabbitMQ users for production workloads.

#Prerequisites

Before you enable TLS, make sure that the following conditions are met:

1. You have a RabbitmqCluster instance.
2. You have a server certificate and private key for the RabbitMQ access names that clients use.
3. The certificate Subject Alternative Name includes the in-cluster service DNS names and any external DNS names or IP addresses used by clients.
4. If clients must verify a private CA, you have the CA certificate.
5. Applications are prepared to use amqps:// and the TLS management endpoint after non-TLS listeners are disabled.

#Procedure

#1. Create TLS secrets

Create a TLS secret in the same namespace as the RabbitmqCluster:

kubectl -n <namespace> create secret tls rabbitmq-server-tls \
  --cert=path/to/tls.crt \
  --key=path/to/tls.key

If clients use a private CA, create a CA secret:

kubectl -n <namespace> create secret generic rabbitmq-ca \
  --from-file=ca.crt=path/to/ca.crt

#2. Configure the RabbitmqCluster

Update the RabbitmqCluster to reference the TLS secret. Include caSecretName when the broker must trust a private CA for mutual TLS or for relevant protocol plugins such as web_stomp and web_mqtt. External AMQP or management clients still need the CA certificate in their own trust store.

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: <instance-name>
  namespace: <namespace>
spec:
  tls:
    secretName: rabbitmq-server-tls
    caSecretName: rabbitmq-ca
    disableNonTLSListeners: true

If you are migrating existing clients, keep disableNonTLSListeners unset or set it to false during the migration window. After all clients use TLS, update the field to true.

#3. Wait for the rollout

Wait until the instance returns to the active phase and all RabbitMQ Pods are ready:

kubectl -n <namespace> get rabbitmqcluster <instance-name>

kubectl -n <namespace> get pods \
  -l app.kubernetes.io/name=<instance-name>

#4. Verify TLS listeners

Check the listener list from a RabbitMQ Pod:

kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmq-diagnostics listeners

For a TLS-only configuration, the output should include TLS listeners and should no longer show plain AMQP or plain HTTP listeners for the disabled protocols.

Also verify the Kubernetes Service ports that are exposed to clients:

kubectl -n <namespace> get svc <instance-name>

#5. Connect with TLS

Use amqps:// for AMQP clients:

amqps://<username>:<password>@<rabbitmq-host>:5671/%2f

%2f is the URL-encoded form of the default / virtual host. Replace it with the URL-encoded virtual host that your application uses.

Use TLS options when running rabbitmqadmin against the management API:

rabbitmqadmin \
  --host <rabbitmq-host> \
  --port <tls-management-port> \
  --ssl \
  --ssl-ca-cert-file path/to/ca.crt \
  --username <username> \
  --password <password> \
  list queues name messages consumers

If the client certificate, key, or CA path is wrong, rabbitmqadmin fails before it can authenticate to RabbitMQ.

#Verification

Use the following checks after enabling TLS:

#Troubleshooting

#Related Information

• Access Methods
• User Management
• Client Connection
• RabbitMQ TLS Support