Cannot set mqtt.ssl_cert_client_id_san_type and san_index

[janezturk]

Describe the bug

I am using docker image version "4.0.2-management". When i have this inside rabbitmq.conf, everything works as expected:

mqtt.listeners.ssl.default = 8883
ssl_cert_login_from = common_name
mqtt.allow_anonymous = false 
mqtt.ssl_cert_login = true
mqtt.ssl_cert_client_id_from = distinguished_name

I get error like this, which is also expected (i commented sensitive data with xxx):

rabbitmq_1    | 2024-10-27 18:31:42.567320+00:00 [error] <0.803.0> MQTT login failed: client_id in the certificate (<<"UID=xxx,CN=xxx,OU=xxx,O=xxx,ST=xxx,C=xxx">>) does not match the client-provided ID (<<"44KwyRc8u7dxkZqGOHX58x">>)

However, when i try this settings:

mqtt.listeners.ssl.default = 8883
ssl_cert_login_from = common_name
mqtt.allow_anonymous = false 
mqtt.ssl_cert_login = true
mqtt.ssl_cert_client_id_from = subject_alternative_name
mqtt.ssl_cert_client_id_san_type = dns
mqtt.ssl_cert_client_id_san_index = 0

Rabbitmq fails like this:

rabbitmq_1    | 2024-10-27 18:35:36.454655+00:00 [error] <0.156.0> You've tried to set mqtt.ssl_cert_client_id_san_type, but there is no setting with that name.
rabbitmq_1    | 2024-10-27 18:35:36.463318+00:00 [error] <0.156.0>   Did you mean one of these?
rabbitmq_1    | 2024-10-27 18:35:36.576373+00:00 [error] <0.156.0>     mqtt.ssl_cert_login_san_type
rabbitmq_1    | 2024-10-27 18:35:36.576441+00:00 [error] <0.156.0>     mqtt.ssl_cert_client_id_from
rabbitmq_1    | 2024-10-27 18:35:36.576481+00:00 [error] <0.156.0>     mqtt.ssl_cert_login_san_index
rabbitmq_1    | 2024-10-27 18:35:36.576627+00:00 [error] <0.156.0> You've tried to set mqtt.ssl_cert_client_id_san_index, but there is no setting with that name.
rabbitmq_1    | 2024-10-27 18:35:36.576645+00:00 [error] <0.156.0>   Did you mean one of these?
rabbitmq_1    | 2024-10-27 18:35:36.675971+00:00 [error] <0.156.0>     mqtt.ssl_cert_login_san_index
rabbitmq_1    | 2024-10-27 18:35:36.676039+00:00 [error] <0.156.0>     mqtt.ssl_cert_client_id_from
rabbitmq_1    | 2024-10-27 18:35:36.676078+00:00 [error] <0.156.0>     mqtt.ssl_cert_login_san_type

I have also tried to set up mqtt.ssl_cert_login_san_type and mqtt.ssl_cert_login_san_index. With this settings rabbitmq doesn't fail, but behaviour is not expected, because it still works even if provided client id doesnt match to DNS.0.

Reproduction steps

1. start rabbitmq:4.0.2-management
2. enable this plugins [rabbitmq_management,rabbitmq_mqtt,rabbitmq_web_mqtt,rabbitmq_ssl]. inside /etc/rabbitmq/enabled_plugins
3. add mqtt.ssl_cert_client_id_san_type = dns or mqtt.ssl_cert_client_id_san_index = 0 in /etc/rabbitmq/rabbitmq.conf
4. restart docker

Expected behavior

RabbitMQ should recognise this settings (that are also in official documentation here https://www.rabbitmq.com/docs/mqtt under "Authentication with TLS/x509 client certificates" section). Furthermore, MQTT login should fail, if client doesn't provide client_id that matches to chosen SAN.

Additional context

No response

[michaelklishin]

@janezturk the nodes suggests the keys to use right in the error message. They come from the rabbitmq.conf schema files found in the core and in the (enabled) plugins, so they are the
source of truth, not the docs:

• mqtt.ssl_cert_client_id_from
• mqtt.ssl_cert_login_san_type
• mqtt.ssl_cert_login_san_index

They were originally introduced in #11702 and backported in 42a8f25.

I suspect that they were renamed since then but the docs were not updated. They will be.

As for the ineffectiveness of the option, it's on you to clearly prove that that is the case. Our team will take a look if you produce an executable way to reproduce with self-signed certificate chains generated using tls-gen. Usually this means a public repo on GitHub that configures RabbitMQ in a certain way and demonstrates exactly what the application does.

"It does not work" is not a detailed description of the problem. We do not guess in this community.

[michaelklishin]

mqtt.ssl_cert_client_id_san_typ had to be renamed to mqtt.ssl_cert_login_san_type, mqtt.ssl_cert_client_id_san_index to mqtt. ssl_cert_login_san_index, and mqtt.ssl_cert_client_id_from was correct rabbitmq/rabbitmq-website@d5f7b3a

[michaelklishin]

The changes are now live.

[michaelklishin]

The MQTT plugin does not log the extracted value right before comparing it to client_id from the session but it might log it at some point at debug level. If that's the case, it should significantly speed up your investigation.

[janezturk]

@michaelklishin thank you for your fast reply and fix in documentation. However, if we look into this file:
rabbitmq-server/deps/rabbitmq_mqtt/src/rabbit_mqtt_processor.erl, specifically at 2234 and 2235 line, there are still this variables used:

extract_client_id_san_type(Mode) ->
    {Mode,
        application:get_env(?APP_NAME, ssl_cert_client_id_san_type, dns),
        application:get_env(?APP_NAME, ssl_cert_client_id_san_index, 0)
    }.

If you think this is unrelated and it should work, I am definitely willing to give you the detailed description of the problem.

[michaelklishin]

@janezturk they are not variables, they are key names. What are the names of the app environment keys that are used internally should not matter to those who use rabbitmq.conf. They do not have match, can have a different level of nesting, can be translated to a different value stored and used internally (e.g. an alias to a module name), and so on.

[michaelklishin]

application:get_env(?APP_NAME, ssl_cert_client_id_san_type, dns) means "I want the value of ssl_cert_client_id_san_type in the final computed MQTT plugin app environment, or dns if none is set"

Renaming ssl_cert_client_id_san_type is possible but won't ship before 4.1.0 in any case.

[janezturk]

@michaelklishin after further investigation, I discovered the following:

• If the client certificate does not contain a Subject Alternative Name (SAN) section, authorization succeeds, even though it should fail.
• When the SAN section is included in the client certificate, the settings for mqtt.ssl_cert_login_san_type and mqtt.ssl_cert_login_san_index have no effect. They are always applied with the default values (dns, 0), regardless of any specified configuration. However, the default setting works as intended, causing login to fail.

We can work with the current behavior for now, but I believe this should be addressed in the future. I’d be happy to provide more details, including the openssl.cnf, certificate generation scripts, rabbitmq.conf, and logs, if that would be helpful. To make it easier, could you let me know exactly what information would be most useful for you?

[michaelklishin]

@MarcialRosales

[michaelklishin]

#12604

[michaelklishin]

Besides the docs update, #12604 turned out to be necessary to make the plugin behaved as described above. This will ship in 4.0.4 but we can provide an alpha build for @janezturk to try long before that, most likely in a few hours.