Dynamic Shovels are not working between both SSL Rabbit brokers

[kadudhularavi]

Describe the bug

I am using the Dynamic shovels between On-prem and Off-prem rabbit brokers. Earlier both are using amqp but recently we moved to TLS broker. After this shovels are not working and getting below error 👍

Shovel 'ICompanyDataFeedStateChangeBatchEvent.xxxx.PlansServicing_UAT' in virtual host 'PlansServicing_UAT' will now try to connect...
2024-11-19 09:46:54.971000+00:00 [error] <0.2336896.0> Shovel 'ICompanyDataFeedStateChangeBatchEvent.xxxx.PlansServicing_UAT' failed to connect (URI: amqps://xxxx/lansServicing_UAT): {options,incompatible,[{verify,verify_peer},{cacerts,undefined}]}
2024-11-19 09:46:54.971000+00:00 [error] <0.2336896.0> Shovel 'ICompanyDataFeedStateChangeBatchEvent.xxxx.PlansServicing_UAT' has no more URIs to try for connection
2024-11-19 09:46:54.971000+00:00 [error] <0.2336896.0> Shovel 'ICompanyDataFeedStateChangeBatchEvent.xxxx.PlansServicing_UAT' could not connect to destination: error failed_to_connect_using_provided_uris
2024-11-19 09:46:54.972000+00:00 [error] <0.2333097.0> supervisor: {<0.2333097.0>,rabbit_shovel_dyn_worker_sup}
2024-11-19 09:46:54.972000+00:00 [error] <0.2333097.0> errorContext: child_terminated
2024-11-19 09:46:54.972000+00:00 [error] <0.2333097.0> reason: {shutdown,normal}

Reproduction steps

NA

Expected behavior

connection should work with TLS

Additional context

No response

[michaelklishin]

@kadudhularavi please use Discussions for question. You haven't provided any evidence of a bug.

Our team will not troubleshoot TLS for you. We have, however, written an extensive guide explaining how to do it efficiently and with minimum guessing.

We do not have RabbitMQ version, Erlang version (yes, it matters), or any details to work with.

There is, however, a hint right in the exception:

{options,incompatible,[{verify,verify_peer},{cacerts,undefined}]}

This Shovel is configured to perform peer verification using the verify setting set to verify_peer but you haven't provided any CA certificates, so the TLS implementation in Erlang
cannot possibly verify the peer's certificate against a list of known anchors (trusted CA certificates).

We do not have any details on what Erlang version is used but we do know — and this is mentioned in the docs and release notes of RabbitMQ 3.13.0, 4.0.1 — that on Erlang 26, peer verification is enabled for client (outgoing) TLS connections by default, including shovels. See Securing Shovel Connections with TLS and if you don't need peer verification, set verify to verify_none for this shovel as demonstrated in the docs.