RabbitMQ 3.13.1 with ECDSA and SHA256withECDSA signature Algorithm certificates not working

[3XC1T3D]

Describe the bug

We want to run RabbitMQ 3.13.1 with ECDSA certificates. We are using ECDSA Certificates on Server and Client (rabbitmq java client 5.21.0) side. After upgrading from 3.12.13 to 3.13.1, the ecdsa support stopped working (using the same certificate and rabbitmq configuration). When we are using the same certificates with RabbitMQ 3.12.13 it works like a charm. We are using the RabbitMQ Docker Image.

Docker Image: 3.12.13 (Erlang: 25.3.2.10) -> working

Docker Image: 3.13.1 (Erlang: 26.2.2) -> not working

When the client side wants to connect to the rabbitmq server we are getting a lot of following error:

2024-04-10 08:34:38.552513+02:00 [notice] <0.2402.0> TLS server: In state hello at ssl_handshake.erl:1749 generated SERVER ALERT: Fatal - Insufficient Security
2024-04-10 08:34:38.552513+02:00 [notice] <0.2402.0>  - no_suitable_signature_algorithm

Reproduction steps

1.Start RabbitMQ 3.13.1 Server with ECDSA and SHA256withECDSA signature Algorithm certificates
2.Connect with rabbitmq java client with ECDSA and SHA256withECDSA signature Algorithm certificates

Expected behavior

RabbitMQ Client can connect with ECDSA and SHA256withECDSA signature Algorithm certificates

Additional context

that is our rabbitmq.conf

ssl_options.certfile = /srv/mounted/config/ssl/certificates/server-cert.crt
ssl_options.keyfile = /srv/mounted/config/ssl/certificates/server-cert.key

# disable tls1.0 and tls1.1
ssl_options.versions.1 = tlsv1.2

# use recommended TLS 1.2 Configuration
# see https://www.rabbitmq.com/ssl.html#tls-evaluation-tools
ssl_options.honor_cipher_order   = true
ssl_options.honor_ecc_order      = true

# These are highly recommended for TLSv1.2 but cannot be used
# with TLSv1.3. If TLSv1.3 is enabled, these lines MUST be removed.
ssl_options.client_renegotiation = false
ssl_options.secure_renegotiate   = true

ssl_options.ciphers.1  = ECDHE-ECDSA-AES256-GCM-SHA384
ssl_options.ciphers.2  = ECDHE-RSA-AES256-GCM-SHA384
ssl_options.ciphers.3  = ECDH-ECDSA-AES256-GCM-SHA384
ssl_options.ciphers.4  = ECDH-RSA-AES256-GCM-SHA384
ssl_options.ciphers.5  = DHE-RSA-AES256-GCM-SHA384
ssl_options.ciphers.6  = DHE-DSS-AES256-GCM-SHA384
ssl_options.ciphers.7  = ECDHE-ECDSA-AES128-GCM-SHA256
ssl_options.ciphers.8  = ECDHE-RSA-AES128-GCM-SHA256
ssl_options.ciphers.9  = ECDH-ECDSA-AES128-GCM-SHA256
ssl_options.ciphers.10 = ECDH-RSA-AES128-GCM-SHA256
ssl_options.ciphers.11 = DHE-RSA-AES128-GCM-SHA256
ssl_options.ciphers.12 = DHE-DSS-AES128-GCM-SHA256

[michaelklishin]

RabbitMQ does not implement TLS, Erlang/OTP does. Not all cipher suites can be used with all protocol versions. There is an example of the most secure combination known (with TLS 1.3 only). There's also a recommended way of testing a TLS setup against a broad range of widely known attacks.

We will not be troubleshooting TLS for non-paying users. If we were to do it, here is how we would approach it. Please take it from here or use a commercial support channel if you do pay for support.

[michaelklishin]

Also note that Erlang 26 changes several defaults and introduces stricter checks around TLS, so maybe it now considers a certain cipher suite not to be compatible with TLS 1.2 where previously it (possibly unintentionally) did.

Again, we will not troubleshoot TLS connectivity for non-paying users.

[3XC1T3D]

Hi @michaelklishin ,

thank you for your answer, We have tested our TLS Setup successfully with the https://testssl.sh, we are also using the recommended TLS 1.2 ciphersuites restriction from the documentation (see above rabbitmq.conf). The used cipher suite is ECDHE-ECDSA-AES256-GCM-SHA384 and it is also part of the supported cipher suites from erlang. We understand that maybe that has nothing to do with rabbitmq, but with the underlining erlang 26.2.2.

Thank you anyway for your answer and we will try to find something in the Erlang documentation :)

[3XC1T3D]

it seams that it is an Erlang Issue: erlang/otp#8376