shovel plugin's TLS client fails with "Handshake Failure\n {bad_cert,hostname_check_failed}" when server sends a wildcard certificate

[andreas-luik]

Describe the bug

The shovel plugin fails to connect to a TLS Server when the server uses a wildcard certificate, the error message is:

2023-06-20 13:00:22.689769+02:00 [error] <0.1604.0> Shovel 'XXX' failed to connect (URI: amqps://server.example.com:5671/service): {tls_alert,{handshake_failure,"TLS client: In state wait_cert_cr at ssl_handshake.erl:2113 generated CLIENT ALERT: Fatal - Handshake Failure\n {bad_cert,hostname_check_failed}"}}

I have followed the https://www.rabbitmq.com/troubleshooting-ssl.html guide and openssl s_client works.

This is on Rocky Linux 8.7 with these RPMs:
rabbitmq-server-3.11.18-1.el8.noarch
erlang-25.3.2.2-1.el8.x86_64

Note: a similar problem has been reported (and fixed) for the Rabbitmq LDAP client in #2805.

Reproduction steps

1. Configure a shovel which uses a destination uri using TLS, where the amqps server uses a wildcard certificate, specify cacertfile, verify=verify_peer, server_name_indication=fqdn.example.com.
2. Observer that the TLS connection fails with the abovementioned error message, even if the server-name/SNI matches the wildcard in the certificates SANs.

Expected behavior

The TLS connection shall succeed (as it does with "openssl s_client").

Additional context

No response

[michaelklishin]

If this is indeed the same issue as #2805, it would require adding URI options for Shovel, Federation, and the AMQP 0-9-1 Erlang client they use, then adding support for a customized hostname verification
similarly to #2806.

It's a real shame that in Erlang's TLS client, hostname verification is lumped together with x.509 certificate chain verification. Those steps are separate and can be enabled or disabled separately in some other TLS clients.