TLS Configuration Issue: Missing ssl_options.password Leads to Non-Functional TLS Listener

[amusarra]

Describe the bug

When RabbitMQ is configured with TLS support but the ssl_options.password parameter is not explicitly set or wrong, the server starts without throwing any exceptions, even if the server.key requires a password. However, the TLS listener (port 5671) is started without any valid certificate configuration, rendering the TLS service unusable.

Reproduction steps

Configure RabbitMQ to enable TLS without specifying ssl_options.password.
Ensure that the server.key file requires a password.

listeners.tcp = none
listeners.ssl.1 = 5671

ssl_options.cacertfile = /etc/rabbitmq/certs/ca.crt
ssl_options.certfile   = /etc/rabbitmq/certs/server.crt
ssl_options.keyfile    = /etc/rabbitmq/certs/server.key
#ssl_options.password   = changeit
ssl_options.verify     = verify_none
ssl_options.fail_if_no_peer_cert = false

ssl_options.versions.1 = tlsv1.3

ssl_options.ciphers.1  = TLS_AES_256_GCM_SHA384
ssl_options.ciphers.2  = TLS_AES_128_GCM_SHA256
ssl_options.ciphers.3  = TLS_CHACHA20_POLY1305_SHA256
ssl_options.ciphers.4  = TLS_AES_128_CCM_SHA256
ssl_options.ciphers.5  = TLS_AES_128_CCM_8_SHA256

ssl_options.honor_cipher_order   = true
ssl_options.honor_ecc_order      = true

File 1 - Content of rabbitmq.conf configuration file

Start the RabbitMQ server.
You can generate certs by following this guide Using tls-gen's Basic Profile

podman run --rm -p5671:5671 -p9000:15672 \ 
  -v ~/rabbitmq-tls/certs:/etc/rabbitmq/certs \
  -v ~/rabbitmq-tls/config/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
  -e RABBITMQ_DEFAULT_USER=quarkus \
  -e RABBITMQ_DEFAULT_PASS=quarkus \
  -e RABBITMQ_LOG=debug \
  rabbitmq:4.0.7-management

Expected behavior

RabbitMQ should fail to start and raise an error indicating that ssl_options.password is required or wrong when the private key is password-protected.

Actual Behavior

RabbitMQ starts without any exception or warning related to the missing or wrong password.

Port 5671 is in a listening state but is not correctly configured with a certificate.

TLS connections fail due to the missing certificate setup.

openssl s_client -showcerts -connect 127.0.0.1:5671 -tls1_3

Connecting to 127.0.0.1
CONNECTED(00000003)
40488A0702000000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:693:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 236 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Suggested Fix

RabbitMQ should validate whether ssl_options.password is required when loading the private key.

If the private key requires a password and it is not provided, RabbitMQ should fail to start with a clear error message.

Environment

RabbitMQ version: 4.0.7
Erlang version: 27.2.4 [jit]
OS (Host): macOS 15.3.2 (24D81)

Additional context

1. StartUp log file rabbitmq_startup_log.txt

[michaelklishin]

@amusarra this is how Erlang's TLS implementation works: certificates are not loaded before the first client connection requests it to be loaded.

What RabbitMQ can validate as part of translating the rabbitmq.conf, it does validate.

RabbitMQ does not implement TLS and this is not going to change.

[amusarra]

Thanks @michaelklishin for the explanation.
I would like to draw attention to this aspect using the keyword: Fast Fail (Fail-Fast).

Fast Fail (Fail-Fast) is a software design principle stating that a system or component should fail immediately when a critical issue is detected, instead of continuing to operate in an uncertain or incorrect state.

The correct behavior would be fail-fast on startup, preventing the server from starting in an incorrect state where TLS is not actually functional.

Even though RabbitMQ uses Erlang Distribution over TLS, could we consider opening an enhancement request to this project Erlang Distribution over TLS?

[lukebakken]

Even though RabbitMQ uses Erlang Distribution over TLS

Not by default - a user must configure the Erlang VM to use TLS for distribution. Your original issue talks about AMQPS connections (i.e. AMQP over TLS), not TLS for Erlang distribution, so I suspect you are confusing the two in your comment.

RabbitMQ is open-source. If you think that RabbitMQ should not start if AMQPS is configured correctly, you are welcome to implement that feature. RabbitMQ has behaved this way for its entire existence, however.

It is rare for users to use X509 certificates that require a password, and those that do, figure out how to configure RabbitMQ correctly.

[michaelklishin]

@amusarra you can cite all the software development principles you want, like I said, RabbitMQ does not implement TLS and this is not going to change.

erlang/otp is where our TLS implementation comes from. It has been lazy loading certificates for a very long time now, so I'd not expect much but you can try convince the Erlang/OTP team that a way to force load certificates and verify the private key password should exist. Then RabbitMQ potentially would have a chance of using such an option early on boot.