cacerts setting doesn't do what we think it does

[lukebakken]

Community Support Policy

• I have read RabbitMQ's Community Support Policy

RabbitMQ version used

4.1.x

How is RabbitMQ deployed?

Other

Steps to reproduce the behavior in question

While working on this PR, I added support for a user to pass several PEM-encoded certificate files to the new /ldap/validate/simple-bind API by adding them to the ssl_options.cacerts section of the JSON body (which has since been renamed, read on...)

What I found, however, is that the cacerts TLS option within Erlang doesn't allow you to pass plain PEM data (link to typespec). The PEM data must first be decoded via public_key:pem_decode/1, the result of that function matched, and the der-encoded binary used as the argument(s) to cacerts.

All this to say that the current ability of users to set cacerts in places like this would never work. Thus, the cacerts setting must never be currently set by RabbitMQ users.

I'm pretty sure there's no way to provide binary data in a cuttlefish settings file to make cacerts work correctly. A user would be able to provide the der-encoded binary in advanced.config, via a term that looks like <<48,130,3,20,48,130,1,252,160,...>> but I'm pretty sure exactly zero RabbitMQ users do this.

As for the /ldap/validate/simple-bind API call, I added support for ssl_options.cacert_pem_data which will correctly decode the passed in certs.

So, should the cacerts setting be removed throughout RabbitMQ? My guess is that if someone wishes to use multiple CA certs, the certs are concatenated into a single PEM file and the cacertfile option is used.

We also now fallback to the system CA certs in some cases thanks to #12564.

[michaelklishin]

The cacerts option is mentioned zero times in the TLS guide. In fact, the guide recommends concatenating trusted CA certificates.