CLIENT ALERT: Fatal - Protocol Version

[wobbet]

Installed RMQ 4.0.5 Docker image using Docker Desktop for WIndows 11 with WSL2 support. I include port mappings for MQTT over TCP and Secure Web Sockets in the docker run command.

I add the MQTT and MQTT Web plugins using the plugin CLI.

Out of the box w/ unsecured TCP (1883) and anonymous auth I'm able to connect using the MQTTNet library. This is running in my VS Code debugger on Windows.

Now I need to get it configured for WebSockets with TLS and client certificates. I go into the docker image and edit the config file to add the following based on the MQTT documentation.

web_mqtt.ssl.port       = 15676
web_mqtt.ssl.backlog    = 1024
web_mqtt.ssl.cacertfile = /etc/rabbitmq/certificates/CA.crt
web_mqtt.ssl.certfile   = /etc/rabbitmq/certificates/MessageBrokerServer.crt
web_mqtt.ssl.keyfile    = /etc/rabbitmq/certificates/MessageBrokerServer.key
# key file is not password protected for dev testing
web_mqtt.ssl.versions.1 = tlsv1.2

Note - the default config file included in the Docker distro is pretty much empty. I do NOT have any other config items related to SSL or TLS. If this is an issue, I'm happy to update my config as needed.

I now update my .NET client code to require SSL and TLS. In the Docker logs for RMQ I get the following error message
025-04-08 22:14:51.777853+00:00 [notice] <0.674.0> TLS server: In state certify received CLIENT ALERT: Fatal - Protocol Version

In my .NET code I receive an exception with the innermost exception in the chain having the error message The Local Security Authority cannot be contacted.

Questions

• What does that RMQ error message mean? I'm specifying TLS1.2 in my .NET client code and the same in RMQ so I'm somewhat confused. I'm guessing it means something other than the obvious that there's a protocol mismatch.
• Have I misconfigured something?
• What's the best way to see what's happening in the TLS negotiation to see if I can get more info? Even w/ debug logging enabled, I am not seeing anything useful in the logs. If a real protocol violation is happening where the client is asking for 1.3 even though I've explicitly asked for 1.2, I'd like to know.

Reproduction steps

1. Do what I did... ???

...

Expected behavior

TLS negotiation to work...

Additional context

The certs are self-signed, and I know that can cause issues, but the error messages are not consistent with those types of errors.

I even disabled sending client certs in my .NET client and it changed nothing. This seems to be happening when the client is connecting to the broker and trying to establish the initial TLS connection with the server. Guessing here...

[lukebakken]

Hello, thanks for using RabbitMQ.

Team RabbitMQ only uses GitHub issues for actionable work, just FYI.

In general, Team RabbitMQ does not provide community support for TLS issues - https://github.com/rabbitmq/rabbitmq-server/blob/main/COMMUNITY_SUPPORT.md#exceptions-question-that-will-be-ignored

Please note we have a guide to diagnosing TLS issues here - https://www.rabbitmq.com/docs/troubleshooting-ssl

I would start by NOT limiting TLS versions or ciphers either your RabbitMQ config or your client config.

Finally, if you take the time to create a git repository on GitHub with a complete, runnable set of code and certificates to observe your issue, I will take a look. I will most likely be able to figure this out, but I do not have time to guess or to set up an environment to try and reproduce what you report.

[michaelklishin]

To add to this, tls-gen can be used to generate self-signed certificate chains for reproduction cases, tests, experimentation.

It should work fine in WSL assuming that OpenSSL, Make and Python 3 do (and I assume they do).

[michaelklishin]

Do what I did... ???

Sure, let me pull out a mind reading device and your private key!

[michaelklishin]

TLS server: In state certify received CLIENT ALERT: Fatal - Protocol Version

The client and the server are configured to use a non-overlapping set of TLS versions.

As already suggested, start without restricting the versions then introduce the restrictions or switch to TLS 1.3, and gradually introduce more restrictions if necessary, e.g. a list of cipher suites.