Document using wildcard certificates for inter-node TLS

[lukebakken]

Is your feature request related to a problem? Please describe.

rabbitmq/rabbitmq-server#10398

It's rare, but some users use wildcard certs for inter-node TLS. We should document the correct way to configure Erlang for this scenario.

[cvuillemez]

Not only for inter-nodes. There is a lack of documentation for federation plugin too.
How to connect to a remote SSL cluster which have wildcard in SAN certificate ?
I tried to pass the following (properly url-encoded) setting in URI parameters :-S :

{customize_hostname_check, [
        {match_fun, public_key:pkix_verify_hostname_match_fun(https)}

[lukebakken]

@cvuillemez in your case you are currently out of luck, and the solution is to not use wildcard certs.

[kmarkovych]

Hi all!
It looks like I have the same issue. I use docker compose environment and wildcard certificate.
That what I got in the log:

2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0> TLS client: In state certify at ssl_handshake.erl:2186 generated CLIENT ALERT: Fatal - Handshake Failure
2024-12-12T16:59:45.468658356Z 2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0>  - {bad_cert,
2024-12-12T16:59:45.468660925Z 2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0>        {hostname_check_failed,
2024-12-12T16:59:45.468662615Z 2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0>            {requested,"localhost.mydomain.com"},
2024-12-12T16:59:45.468664217Z 2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0>            {received,
2024-12-12T16:59:45.468665658Z 2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0>                [{dNSName,"*.mydomain.com"},
2024-12-12T16:59:45.468667135Z 2024-12-12 16:59:45.466207+00:00 [notice] <0.619.0>                 {dNSName,"mydomain.com"}]}}}
2024-12-12T16:59:45.472072084Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0> HTTP access denied: Authentication using an OAuth 2/JWT token failed: {error,
2024-12-12T16:59:45.472090590Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                    {failed_connect,
2024-12-12T16:59:45.472092531Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                     [{to_address,
2024-12-12T16:59:45.472094022Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                       {"localhost.mydomain.com",
2024-12-12T16:59:45.472095512Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                        443}},
2024-12-12T16:59:45.472103368Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                      {inet,
2024-12-12T16:59:45.472104483Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                       [inet],
2024-12-12T16:59:45.472105515Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                       {tls_alert,
2024-12-12T16:59:45.472106551Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                        {handshake_failure,
2024-12-12T16:59:45.472107781Z 2024-12-12 16:59:45.471799+00:00 [warning] <0.613.0>                                                         "TLS client: In state certify at ssl_handshake.erl:2186 generated CLIENT ALERT: Fatal - Handshake Failure\n {bad_cert,\n     {hostname_check_failed,\n         {requested,\"localhost.mydomain.com\"},\n         {received,\n             [{dNSName,\"*.mydomain.com\"},\n              {dNSName,\"mydomain.com\"}]}}}"}}}]}}

Could you help me to solve that?

[michaelklishin]

@kmarkovych this is not a support forum. This is a specific, actionable item for RabbitMQ documentation. Perhaps consider https://github.com/rabbitmq/rabbitmq-server/discussions next time.

Our community support policy explicitly states that we will not troubleshoot networking for non-paying users, so no, we cannot help you with this question.

We do have a documentation guide that explains how to narrow down TLS-specific connectivity issues efficiently and with as little guessing as possible.