RabbitMQ 4.4.0 Message Broker

• In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration.
• Pick RabbitMQ 4.4.0 Message Broker on Ubuntu 24.04 as the software version, and pick your Region.
• Choose Launch through EC2.
• Choose m5.large (or larger for many connections or high message rates), your key pair and a security group as above.

Or launch with the AWS CLI. Replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=rabbitmq-broker}]'

The image requires IMDSv2 (session tokens). First boot takes about a minute after the instance is running:

• The boot service reads the instance's EC2 names.
• It creates the Erlang cookie, the logins and the certificate.
• The broker starts and loads the logins.
• The guard checks the broker.

Version SSH user

RabbitMQ 4.4.0 Message Broker on Ubuntu 24.04 ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

The login banner shows where the logins and the certificate are stored.

systemctl is-active rabbitmq-metadata-names rabbitmq-firstboot rabbitmq-server nginx
sudo ss -tlnp | grep -E ':(22|443|1883|4369|5552|5671|5672|15672|15692|25672|61613) '
sudo ss -ulnp | grep -E 'beam|epmd|nginx' || echo 'no UDP socket'

active active active active LISTEN 0 4096 127.0.0.1:4369 0.0.0.0:* users:(("epmd",pid=1125,fd=3)) LISTEN 0 1024 127.0.0.1:15672 0.0.0.0:* users:(("beam.smp",pid=1054,fd=30)) LISTEN 0 128 127.0.0.1:25672 0.0.0.0:* users:(("beam.smp",pid=1054,fd=19)) LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1059,fd=5),("nginx",pid=1058,fd=5),("nginx",pid=1057,fd=5)) LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1255,fd=3),("systemd",pid=1,fd=59)) LISTEN 0 128 *:5671 *:* users:(("beam.smp",pid=1054,fd=38)) LISTEN 0 4096 [::1]:4369 [::]:* users:(("epmd",pid=1125,fd=4)) LISTEN 0 4096 [::]:22 [::]:* users:(("sshd",pid=1255,fd=4),("systemd",pid=1,fd=60)) no UDP socket

The four units are:

• rabbitmq-metadata-names reads this instance's EC2 names for the certificate.
• rabbitmq-firstboot prepares the cookie, the logins and the certificate.
• rabbitmq-server is the broker, the Erlang VM beam.smp.
• nginx serves the console on 443.

The broker listens on 5671 (AMQPS) on every address. Everything else it opens is on 127.0.0.1 only: the console backend (15672, for nginx), Erlang distribution (25672) and epmd (4369).

Everything generated for your instance is in /root/rabbitmq-credentials.txt, which only root can read. View it with sudo cat /root/rabbitmq-credentials.txt. These lines are not secret:

sudo grep -E '^RABBITMQ_(HOST|AMQPS_ENDPOINT|AMQPS_PORT|MGMT_URL|PRIVATE_IP|ADMIN_USER|APP_USER|APP_VHOST|APP_PREFIX|TLS_CERT_FILE|TLS_CERT_SHA256|TLS_PUBKEY_SHA256)=' /root/rabbitmq-credentials.txt

RABBITMQ_HOST=54.210.149.54 RABBITMQ_AMQPS_ENDPOINT=amqps://54.210.149.54:5671 RABBITMQ_AMQPS_PORT=5671 RABBITMQ_MGMT_URL=https://54.210.149.54/ RABBITMQ_PRIVATE_IP=172.31.91.20 RABBITMQ_ADMIN_USER=sac-admin RABBITMQ_APP_USER=sac-app RABBITMQ_APP_VHOST=sac-app RABBITMQ_APP_PREFIX=app. RABBITMQ_TLS_CERT_FILE=/etc/rabbitmq/tls/rabbitmq.crt RABBITMQ_TLS_CERT_SHA256=77:87:22:5D:8F:BC:8E:66:E2:5C:93:3F:B0:6A:CE:63:B6:51:78:41:89:24:00:C6:1B:15:AF:45:46:20:F6:3B RABBITMQ_TLS_PUBKEY_SHA256=3c0bdcdd3671b8cdc2bd37b37b7e835a625ff090880affc8c6883ab9185feef8

The file also holds RABBITMQ_ADMIN_PASSWORD and RABBITMQ_APP_PASSWORD. It does not hold the Erlang cookie (Step 10).

Give applications the sac-app login or a scoped user of their own (Step 8), never the administrator's login. Keep passwords in files with mode 0600, not in shell history or on command lines, because every user on a machine can see a command line through ps.

The broker's certificate is self-signed, made on your instance:

sudo openssl x509 -in /etc/rabbitmq/tls/rabbitmq.crt -noout -subject -enddate -ext subjectAltName,basicConstraints
sudo openssl x509 -in /etc/rabbitmq/tls/rabbitmq.crt -noout -fingerprint -sha256

subject=CN = rabbitmq-broker, O = sac notAfter=Feb 10 06:04:15 2029 GMT X509v3 Subject Alternative Name: IP Address:54.210.149.54, DNS:ec2-54-210-149-54.compute-1.amazonaws.com, IP Address:172.31.91.20, DNS:ip-172-31-91-20.ec2.internal, IP Address:127.0.0.1, DNS:localhost X509v3 Basic Constraints: critical CA:FALSE sha256 Fingerprint=77:87:22:5D:8F:BC:8E:66:E2:5C:93:3F:B0:6A:CE:63:B6:51:78:41:89:24:00:C6:1B:15:AF:45:46:20:F6:3B

CA:FALSE means it is an end-entity certificate that cannot sign anything else. The SHA-256 fingerprint is the RABBITMQ_TLS_CERT_SHA256 value in your credentials file, and the same certificate is served on 5671 and on 443.

The certificate is public, and the private key never leaves the instance. Copy the certificate to each client machine:

client-host$ ssh -i <your-key.pem> ubuntu@<public-ip> 'sudo cat /etc/rabbitmq/tls/rabbitmq.crt' > rabbitmq.crt client-host$ openssl x509 -in rabbitmq.crt -noout -fingerprint -sha256

Compare the fingerprint with RABBITMQ_TLS_CERT_SHA256 before you trust the file. Then set your client's CA file or trust store to only this file, with host name checking on. Your client then refuses any other server, including a server in the middle that presents a different certificate.

The certificate covers the instance's public and private IPv4 addresses, its EC2 DNS names, localhost and 127.0.0.1. An EC2 stop and start gives the instance a new public IP. At the next boot, the certificate is re-issued for the new names with the same key:

• Clients that pin the public key (RABBITMQ_TLS_PUBKEY_SHA256) keep working.
• Clients that pin the certificate file need the new copy.

rabbitmq-probe is a small AMQP client. It reads passwords from a file (or from the credentials file with --identity), and it trusts only the broker's certificate:

sudo rabbitmq-probe connect --identity app
sudo rabbitmq-probe roundtrip --identity app --queue app.guide-test
sudo rabbitmq-probe declare --identity app --queue orders || true
sudo rabbitmq-probe connect --identity app --vhost / || true

OPEN ok vhost=sac-app tls=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 ROUNDTRIP OK queue=app.guide-test bytes=56 tls=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 CHANNEL-CLOSE 403 ACCESS_REFUSED - configure access to queue 'orders' in vhost 'sac-app' refused for user 'sac-app' REFUSED 530 NOT_ALLOWED - access to vhost '/' refused for user 'sac-app'

These four commands show that:

• The application user logs in.
• It declares a queue named app.guide-test, publishes a message and reads it back.
• It is refused a queue outside app.*.
• It is refused the / virtual host.

rabbitmq-probe exits non-zero on a refusal, hence the || true.

On the client machine, put the application password in a file that only you can read. Then copy the certificate as in Step 5:

client-host$ umask 077 client-host$ ssh -i <your-key.pem> ubuntu@<public-ip> "sudo sed -n 's/^RABBITMQ_APP_PASSWORD=//p' /root/rabbitmq-credentials.txt" > app.password

This example uses Python and pika (sudo apt-get install python3-pika on Ubuntu, or pip install pika):

# pika_demo.py - publish and consume through your sac RabbitMQ broker over AMQPS (pika 1.x).
# Usage:
python3 pika_demo.py <broker-host> <rabbitmq.crt> <user> <password-file> <vhost> <queue>
# The password is read from a file, never the command line; TLS trusts ONLY the broker's own certificate. import ssl import sys import pika host, cafile, user, pwfile, vhost, queue = sys.argv[1:7] with open(pwfile) as f: password = f.read().strip() ctx = ssl.create_default_context(cafile=cafile) # verify against this one certificate, nothing else ctx.minimum_version = ssl.TLSVersion.TLSv1_2 params = pika.ConnectionParameters( host=host, port=5671, virtual_host=vhost, credentials=pika.PlainCredentials(user, password), ssl_options=pika.SSLOptions(ctx, server_hostname=host), ) conn = pika.BlockingConnection(params) ch = conn.channel() ch.queue_declare(queue=queue, durable=True) ch.basic_publish(exchange="", routing_key=queue, body=b"hello from pika", properties=pika.BasicProperties(delivery_mode=2)) method, props, body = ch.basic_get(queue=queue, auto_ack=True) print("received:", body.decode()) conn.close()

client-host$ python3 pika_demo.py <public-ip> rabbitmq.crt sac-app app.password sac-app app.pika-demo received: hello from pika

For <broker-host>, use a name the certificate covers: the public or private IP, an EC2 DNS name, or your own DNS name once you have added it (Step 12).

The AMQP URL form is amqps://sac-app:<password>@<public-ip>:5671/sac-app, and most libraries accept it. Build it inside your program from the password file. Do not write it in a configuration file or on a command line.

Open https://<public-ip>/ in a browser and sign in as sac-admin with RABBITMQ_ADMIN_PASSWORD. The certificate is self-signed, so the browser warns until you trust rabbitmq.crt or install a CA certificate (Step 12).

The HTTP API is served at the same address. On the instance:

• Keep the administrator login in a curl configuration file that only you can read.
• Copy the certificate where your user can read it.
• Check the API. A request with no login gets 401.

umask 077
sudo cat /etc/rabbitmq/tls/rabbitmq.crt > ~/rabbitmq.crt printf 'user = "sac-admin:%s"\n' "$(sudo sed -n 's/^RABBITMQ_ADMIN_PASSWORD=//p' /root/rabbitmq-credentials.txt)" > ~/.rabbitmq-admin.curl api() { curl -sS --cacert ~/rabbitmq.crt -K ~/.rabbitmq-admin.curl "$@"; } api -o /dev/null -w '%{http_code}\n' https://localhost/api/overview curl -sS --cacert ~/rabbitmq.crt -o /dev/null -w '%{http_code}\n' https://localhost/api/overview

200 401

Give each application its own user, limited to its own virtual host and name prefix, rather than sharing one login. The safe way on the instance is rabbitmqctl with the password on standard input.

Run rabbitmqctl add_user with only the user name, and redirect the password file into it. It then reads the password from the file, so the password never appears in ps, your shell history or the broker log. Never pass the password as a second argument.

The example below sets up:

• A virtual host orders
• A user orders-svc with a random password kept in a 0600 file
• Permissions limited to names that start with orders.

umask 077
sudo rabbitmqctl add_vhost orders openssl rand -base64 30 | tr -d '/+=\n' | head -c 32 > ~/orders-svc.password
sudo rabbitmqctl add_user orders-svc < ~/orders-svc.password
sudo rabbitmqctl set_permissions -p orders orders-svc '^orders\.' '^(orders\..*|amq\.default)?$' '^orders\.'

Adding vhost "orders" ... Adding user "orders-svc" ... Password: Done. Don't forget to grant the user permissions to some virtual hosts! See 'rabbitmqctl help set_permissions' to learn more. Setting permissions for user "orders-svc" in vhost "orders" ...

The write pattern also allows amq.default, the default exchange, so the application can publish straight to its own queues by name. Try the new user:

sudo rabbitmq-probe roundtrip --user orders-svc --password-file ~/orders-svc.password --vhost orders --queue orders.created
sudo rabbitmq-probe declare --user orders-svc --password-file ~/orders-svc.password --vhost orders --queue app.x || true
sudo rabbitmq-probe connect --user orders-svc --password-file ~/orders-svc.password --vhost sac-app || true

ROUNDTRIP OK queue=orders.created bytes=56 tls=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 CHANNEL-CLOSE 403 ACCESS_REFUSED - configure access to queue 'app.x' in vhost 'orders' refused for user 'orders-svc' REFUSED 530 NOT_ALLOWED - access to vhost 'sac-app' refused for user 'orders-svc'

To rotate the password, use the same standard-input form:

umask 077 openssl rand -base64 30 | tr -d '/+=\n' | head -c 32 > ~/orders-svc.password.new
sudo rabbitmqctl change_password orders-svc < ~/orders-svc.password.new && mv ~/orders-svc.password.new ~/orders-svc.password

Hand ~/orders-svc.password to the application's secret store, then delete it with shred -u ~/orders-svc.password. To remove the example again:

sudo rabbitmqctl delete_user orders-svc
sudo rabbitmqctl delete_vhost orders shred -u ~/orders-svc.password 2>/dev/null || true

From another machine, manage the broker over HTTPS on 443 with the console or the HTTP API (https://<public-ip>/api/... with --cacert rabbitmq.crt). When you create a user through the API, send the password in a JSON request body read from a 0600 file (--data @file). Never put it in the URL or on the command line.

The broker enforces these rules whatever you change:

• No user may be called guest.
• No user may have the password guest, an empty password, a common default or its own name.
• sac-admin can use AMQP only from the instance itself (loopback_users).

rabbitmq-server.service runs rabbitmq-config-gate before every start and rabbitmq-guard after it. Check both, and the whole instance, at any time:

sudo rabbitmq-config-gate --unit && echo gate-ok
sudo rabbitmq-selfcheck | tail -n 1

rabbitmq-config-gate: OK (unit) gate-ok SELFCHECK OK

The gate. It runs before every start. It refuses changes like these:

• In /etc/rabbitmq/rabbitmq.conf or a conf.d/*.conf file: a plain-text listener (listeners.tcp.*, or a plugin's plain port off loopback), a console bound to the network, a non-loopback guest, the ANONYMOUS mechanism, a TLS version below 1.2, or an external authentication backend.
• An advanced.config file.
• In enabled_plugins: a plugin whose plain-text listener would be public. MQTT, STOMP and Stream need their plain listener set to none or to a 127.0.0.1 address (use their TLS listener for the network). Web-MQTT, Web-STOMP and Prometheus need their HTTP listener on 127.0.0.1. The gate also refuses the LDAP, HTTP and OAuth 2 authentication backends, peer discovery (clustering) and message tracing.
• Changes to rabbitmq-env.conf (the loopback-only Erlang distribution).

If the gate refuses a change, the broker does not start, and journalctl -u rabbitmq-server shows the reason.

The guard. It runs after every start. It stops the broker if the broker has:

• A user called guest, a user with a weak password, or a user with no password
• A management API that answers without a login
• Any listener other than the expected set

rabbitmq-selfcheck prints one ok: line per area and ends with SELFCHECK OK. The areas are the units, the gate and the guard, the Erlang cookie, the listening set, the certificate, round trips, refusals, the console and the metadata block.

By default, RabbitMQ serves:

• Plain AMQP on 5672 and the HTTP console on 15672, both without TLS
• epmd on 4369 and Erlang distribution on 25672, on every address

Its first start also creates guest / guest. On a cloud instance, that means passwords and messages in clear text, a well-known login, and a node that anyone holding the cookie can control over the network. This image closes each of these in RabbitMQ's own configuration, not with a firewall:

• 5672 (AMQP) is off. Use AMQPS on 5671. Every maintained AMQP client supports TLS.
• 15672 (HTTP console and API) is bound to 127.0.0.1 for nginx only. Use https://<host>/ on 443.
• 4369 (epmd) and 25672 (Erlang distribution) are bound to 127.0.0.1, set in /etc/rabbitmq/rabbitmq-env.conf. The node is rabbit@localhost. Only processes on this instance can reach it, which is what rabbitmqctl needs. This image is a single node. Clustering would need distribution on the network, and the gate refuses that.
• MQTT (1883), STOMP (61613), Stream (5552) and Prometheus (15692) are not enabled.

epmd -names sudo stat -c '%n %a %U:%G %s bytes' /var/lib/rabbitmq/.erlang.cookie /var/lib/rabbitmq

epmd: up and running on port 4369 with data: name rabbit at port 25672 /var/lib/rabbitmq/.erlang.cookie 400 rabbitmq:rabbitmq 64 bytes /var/lib/rabbitmq 750 root:rabbitmq 4096 bytes

The Erlang cookie is the shared secret that lets an Erlang process join the node or control it with rabbitmqctl. Anyone who has it and can reach the distribution port has full control of the broker. On this image:

• The cookie is 256 random bits, generated on your instance at first boot. No two instances share one, and the image ships none.
• It is readable only by the rabbitmq user (0400), in a home directory that root owns.
• It is not in the credentials file, and you never need to copy it. sudo rabbitmqctl on the instance reads it for you.
• The distribution port is on loopback, so the cookie is useless from another machine.

If you delete the cookie, the next boot mints a new one.

The EC2 instance metadata service (169.254.169.254) hands out the instance's IAM role credentials to any process that asks. A broker or web server that could be tricked into fetching a URL must not be able to reach it.

These units run with the metadata addresses blocked by systemd (IPAddressDeny):

• rabbitmq-server, and the epmd daemon it starts in its own control group
• nginx
• rabbitmq-firstboot

Only rabbitmq-metadata-names, which reads the instance's names for the certificate, may reach the metadata service, and it may reach nothing else:

for u in rabbitmq-server nginx rabbitmq-firstboot rabbitmq-metadata-names; do printf '%-24s deny=%s allow=%s\n' "$u" "$(systemctl show -p IPAddressDeny --value "$u")" "$(systemctl show -p IPAddressAllow --value "$u")"; done

rabbitmq-server deny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 ::ffff:168.63.129.16/128 allow= nginx deny=::ffff:168.63.129.16/128 169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 ::ffff:169.254.169.254/128 allow= rabbitmq-firstboot deny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 ::ffff:168.63.129.16/128 ::ffff:169.254.169.254/128 allow= rabbitmq-metadata-names deny=0.0.0.0/0 ::/0 allow=169.254.169.254/32 fd00:ec2::254/128

rabbitmq-selfcheck proves the block from inside the broker's own control group: a request to the metadata service gets no answer, while a request to the instance's own console succeeds.

RabbitMQ has no telemetry. The image enables no plugin that dials out (no Federation, Shovel or Prometheus), so the broker opens no outbound connection.

Point a DNS name at the instance (an Elastic IP keeps the address across stop and start), then add the name to the certificate:

sudo rabbitmq-set-hostname <dns-name>

This command:

• Re-issues the self-signed certificate, with the same key, to cover the name
• Pins nginx to the name
• Updates the endpoint in /root/rabbitmq-credentials.txt
• Restarts the broker

Copy the new rabbitmq.crt to clients that pin the certificate file.

To use a certificate from your CA (your own, or a public one such as Let's Encrypt), copy the chain (server certificate first) and its unencrypted PEM key to the instance, then run:

sudo rabbitmq-install-cert <certificate-chain.pem> <private-key.pem> <dns-name>

Both endpoints (5671 and 443) then serve your certificate, and clients trust your CA instead of pinning this instance. The boot-time renewal never replaces an installed certificate. To go back to a new self-signed certificate, run sudo rabbitmq-set-hostname <name>.