Port 5671 – AMQP over TLS

TCP

Port 5671 is the AMQP (Advanced Message Queuing Protocol) TLS port – the encrypted equivalent of port 5672. RabbitMQ and other AMQP brokers serve encrypted connections on port 5671. Use port 5671 for all production message queue connections to protect credentials and message contents from network interception.

Port Number

5671

Protocol

TCP

Service

AMQP 0-9-1 (SSL/TLS)

Range

IANA Registered (1024–49151)

Description

AMQP over TLS on port 5671 provides encrypted message broker connections. RabbitMQ, Apache Qpid, and other AMQP brokers serve this port for clients that require transport encryption. The TLS connection wraps the entire AMQP protocol – authentication credentials, routing keys, and message payloads are all encrypted. RabbitMQ requires explicit TLS listener configuration for port 5671 – it is not enabled by default. Configure ssl_options in rabbitmq.conf with the server certificate, private key, and CA certificate. Client connections to port 5671 must trust the broker's CA. For mutual TLS (mTLS), configure verify_peer = true and fail_if_no_peer_cert = true to require client certificates.

Security risks

1TLS misconfiguration: enabling 5671 without disabling 5672 means clients can still connect unencrypted – both ports active simultaneously is a common mistake
2Weak cipher suites: older RabbitMQ versions default to allowing TLS 1.0/1.1 and weak ciphers on port 5671 unless explicitly restricted in rabbitmq.conf
3Client certificate validation disabled: many deployments set ssl_options.verify = verify_none, allowing any client with network access to connect even with invalid certificates
4Certificate rotation downtime: when updating TLS certificates on 5671, misconfigured clusters can lose all AMQP connections simultaneously (no graceful reload in older RabbitMQ)
5Same credential vulnerabilities as 5672: TLS encrypts the wire but default guest/guest credentials still work if not removed, and brute-force attacks work over TLS too

Firewall guidance

In production: enable only port 5671 (TLS) and disable port 5672 (plaintext). Configure rabbitmq.conf: listeners.tcp = none, listeners.ssl.default = 5671. Require client certificates for mutual TLS (ssl_options.verify = verify_peer, ssl_options.fail_if_no_peer_cert = true). This authenticates clients cryptographically in addition to username/password.

Diagnosis commands

Test AMQPS TLS connection and inspect server certificate

shell

openssl s_client -connect rabbit:5671 -showcerts

List active RabbitMQ listeners (verify 5672 is disabled)

shell

rabbitmqctl eval 'rabbit_networking:active_listeners().'

Check TLS version and cipher in use

shell

echo | openssl s_client -connect rabbit:5671 2>/dev/null | grep 'Protocol\|Cipher'

Show TLS versions supported by the RabbitMQ node

shell

rabbitmq-diagnostics tls_versions

Usage examples

Port 5671 – AMQP over TLS

shell

rabbitmqctl eval 'rabbit_networking:active_listeners().'
openssl s_client -connect broker:5671
amqp-consume --url amqps://user:pass@broker:5671 -q myqueue cat

Common services on this port

RabbitMQ (TLS listener)Apache QpidAzure Service BusAmazon MQ (managed RabbitMQ)LavinMQ

Related ports

5671

AMQPS (this port, TLS)

5672

AMQP (plaintext)

15672

RabbitMQ Management UI

4369

EPMD (Erlang cluster discovery)

History

Port 5671 was registered for AMQP over TLS (AMQPS) alongside 5672 (plaintext AMQP) in the AMQP 0-9-1 specification era. RabbitMQ added TLS support early in its development. The implicit TLS model (like HTTPS on 443) was chosen over STARTTLS for simplicity. Amazon MQ and Azure Service Bus provide managed RabbitMQ/AMQP with mandatory TLS, eliminating the configuration burden.

FAQ

How do I configure RabbitMQ for TLS-only?

In rabbitmq.conf: listeners.tcp = none (disables 5672), listeners.ssl.default = 5671, ssl_options.cacertfile = /path/ca.pem, ssl_options.certfile = /path/server.pem, ssl_options.keyfile = /path/server-key.pem, ssl_options.versions.1 = tlsv1.3, ssl_options.versions.2 = tlsv1.2, ssl_options.verify = verify_peer, ssl_options.fail_if_no_peer_cert = true. Restart RabbitMQ. Update all clients to use amqps:// URLs.

Do I need client certificates or is server-side TLS enough?

Server-side TLS (verify = verify_none): encrypts traffic but any client with valid credentials can connect. Good enough when: clients are trusted internal services with strong passwords. Mutual TLS (verify = verify_peer + fail_if_no_peer_cert = true): cryptographically verifies client identity. Required when: clients cross trust boundaries, you want zero-trust auth, or compliance mandates mutual authentication. Mutual TLS makes stolen credentials useless without the client certificate.

Specification

RFC 7049 – Port 5671 specification →