Rabbitmq: Avoid using legacy configuration keys such as management.listener.ssl

[michaelklishin]

This image provisions the latest RabbitMQ but still uses legacy (pre-3.7.9, soon to be 1 year old) settings to configure HTTP(S) API's TCP and TLS settings: management.listener.* specifically.

Consider using management.tcp.* and management.ssl.* instead. They are consistent with the core listener settings and easier to remember. They also make it possible to configure both HTTP and HTTPS listeners side by side which was not possible with a single set of options (management.listener.*).

[michaelklishin]

I've noticed we still have a couple of deprecated keys in doc examples. I will take care of those.

[LHCGreg]

Related to this, if you set RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS environment variables and have management.tcp.request_timeout = 120000 in rabbitmq.conf, then rabbitmq.conf after the docker entrypoint is done is

management.tcp.request_timeout = 120000
loopback_users.guest = false
listeners.tcp.default = 5672
default_pass = rabbitmq_password
default_user = rabbitmq
management.listener.port = 15672
management.listener.ssl = false

which causes rabbit to crash with

2019-09-12 15:13:29.595 [debug] <0.490.0> Starting HTTP[S] listener with transport ranch_tcp, options [{port,15672}] and protocol options #{idle_timeout => 120000,inactivity_timeout => 120000,request_timeout => 120000,sendfile => false}, stream handlers [rabbit_cowboy_stream_h,cowboy_compress_h,cowboy_stream_h]
2019-09-12 15:13:29.596 [error] <0.490.0> ** Generic server rabbit_web_dispatch_registry terminating
** Last message in was {add,rabbitmq_management_tcp,[{cowboy_opts,[{idle_timeout,120000},{inactivity_timeout,120000},{request_timeout,120000},{sendfile,false}]},{port,15672}],#Fun<rabbit_web_dispatch.0.72790530>,[{'_',[],[{[],[],cowboy_static,{priv_file,rabbitmq_management,"www/index.html"}},{[<<"api">>,<<"overview">>],[],rabbit_mgmt_wm_overview,[]},{[<<"api">>,<<"cluster-name">>],[],rabbit_mgmt_wm_cluster_name,[]},{[<<"api">>,<<"nodes">>],[],rabbit_mgmt_wm_nodes,[]},{[<<"api">>,<<"nodes">>,node],[],rabbit_mgmt_wm_node,[]},{[<<"api">>,<<"nodes">>,node,<<"memory">>],[],rabbit_mgmt_wm_node_memory,[absolute]},{[<<"api">>,<<"nodes">>,node,<<"memory">>,<<"relative">>],[],rabbit_mgmt_wm_node_memory,[relative]},{[<<"api">>,<<"nodes">>,node,<<"memory">>,<<"ets">>],[],rabbit_mgmt_wm_node_memory_ets,...},...]}],...}
** When Server state == undefined
** Reason for termination ==
** {{incompatible_listeners,{"RabbitMQ Management",[{cowboy_opts,[{idle_timeout,120000},{ina

[tianon]

Nice! Are either of management.listener.ssl_opts.fail_if_no_peer_cert and/or management.listener.ssl_opts.verify still relevant?
(I don't think management.ssl.verify or management.ssl.fail_if_no_peer_cert exist)

What about management.ssl.depth? (I don't have an example of that one, but it's one our script has supported -- the other two we have default values for.)

[michaelklishin]

Oh, those two slipped through the cracks. I will add them for 3.7.18.

[michaelklishin]

I'm reminded that these settings are for the HTTP API and management UI, and requiring all HTTP API clients to present a certificate chain is not always a good idea. We will add the options for completeness and consistency with the messaging protocol listener settings.

[michaelklishin]

3.7.18 includes the above mentioned management.ssl.* keys.

[michaelklishin]

management.ssl.depth (max traversed peer verification chain depth) is supported since https://github.com/rabbitmq/rabbitmq-management/commit/34e2113508fd39fed3a01529d86bc0a1905bc25f.