RabbitMQ node does not load TLS certificate or private key on boot

[Shadouw]

Describe the bug

I tried to get RabbitMQ running with TLS encryption and ran into Socket Exceptions from both, client and browser. It turned out, that I used a wrong key format as RABBITMQ_SERVER_KEY_PEM. I can use any file, even log files or any other plain text file, and RabbitMQ starts without issues.

The log file doesn't show any issue while starting and reports a succesful start:

2025-12-04 15:50:15.045000+01:00 [info] <0.590.0> Management plugin: HTTPS listener started on port 15672
2025-12-04 15:50:15.045000+01:00 [info] <0.621.0> Statistics database started.
2025-12-04 15:50:15.045000+01:00 [info] <0.620.0> Starting worker pool 'management_worker_pool' with 3 processes in it
2025-12-04 15:50:15.046000+01:00 [info] <0.524.0> Applying definitions from file at 'SOMEPATHTO/definitions.json'
2025-12-04 15:50:15.046000+01:00 [info] <0.524.0> Asked to import definitions. Acting user: rmq-internal
2025-12-04 15:50:15.046000+01:00 [info] <0.524.0> Importing concurrently 1 users...
2025-12-04 15:50:15.090000+01:00 [info] <0.524.0> Importing concurrently 1 vhosts...
2025-12-04 15:50:15.106000+01:00 [info] <0.524.0> Importing concurrently 1 permissions...
2025-12-04 15:50:15.146000+01:00 [info] <0.515.0> Successfully set permissions for user 'rabbitmq' in virtual host '/' to '.*', '.*', '.*'
2025-12-04 15:50:15.146000+01:00 [info] <0.524.0> Ready to start client connection listeners
2025-12-04 15:50:17.849000+01:00 [info] <0.663.0> started TLS (SSL) listener on [::]:5671
2025-12-04 15:50:17.993000+01:00 [info] <0.683.0> started TLS (SSL) listener on 0.0.0.0:5671
 completed with 3 plugins.
2025-12-04 15:50:18.159000+01:00 [info] <0.524.0> Server startup complete; 3 plugins started.
2025-12-04 15:50:18.159000+01:00 [info] <0.524.0>  * rabbitmq_management
2025-12-04 15:50:18.159000+01:00 [info] <0.524.0>  * rabbitmq_management_agent
2025-12-04 15:50:18.159000+01:00 [info] <0.524.0>  * rabbitmq_web_dispatch
2025-12-04 15:50:18.211000+01:00 [info] <0.9.0> Time to start RabbitMQ: 21337 ms

But unfortunatley neither http nor https connections are working even though RabbitMQ is listening on the ports.

Reproduction steps

...

Expected behavior

RabbitMQ should fail if it can't use the configured server key file.

Additional context

No response

[lukebakken]

Yes, this is how the underlying Erlang runtime works. You won't get an error until the first attempt to use those files to create a TLS-encrypted TCP connection.

[lukebakken]

Hm, so there are two issues here -

• Nothing is logged when a connection is attempted when completely invalid certificate files are in place.
• RabbitMQ should at least verify that the certificate files contain valid PEM / X509 data (easy to do via public_key:pem_decode/1)

@michaelklishin I'll continue working on this.

[michaelklishin]

The first point was brought up with the Erlang/OTP maintainers and there were some improvements.

The second one can be solved with a new Cuttlefish validation. We should already validate that the file paths exist and are readable (for all files).

[michaelklishin]

@Shadouw a TLS connection that forces an invalid, say, private key file to load will fail at the TLS implementation level. RabbitMQ or any of its dependencies that start protocol listeners (such as Cowboy for HTTP) won't see an inbound connection or request. This is very standard.

What is not standard about Erlang's TLS implementation is that it uses a certificate and private key cache heavily, and the cache is first populated when the first TLS-enabled connection comes in.

Nginx would fail to even boot with an invalid certificate. That's what @lukebakken and I are discussing, possibly behind and option or starting with 4.3.0 that can include some breaking changes without attracting much attention of the The Church of SemVer Everywhere cult.

[lukebakken]

The bare minimum - #15071

[Zerpet]

I'm a bit late to the party, but I want to leave my thoughts too. I agree this behaviour can be improved. I was bitten by this back in my customer support days, and I had to use openssl cli to find out that my certs were invalid.

I think the approach to validate TLS certificate format, already in progress in #15071 (thanks @lukebakken !) is the right thing to do. IIUC, that PR will address both concerns raised in this discussion (no logging + file validation).