Rabbit Management ignores auth_mechanisms

[Rob A.]

Hello,

Currently I'm setting up the authentication for the rabbit management with X.509 TLS authentication.

I could enable the ssl socket to ask for the client certificate with these options in rabbitmq.conf (by the way: these should be added in the documentation http://www.rabbitmq.com/management.html):

management.listener.ssl_opts.verify  = verify_peer
management.listener.ssl_opts.fail_if_no_peer_cert = true

Plus the certificate options which are added by my docker entrypoint to the rabbitmq.conf:

rabbit_set_config 'management.listener.ssl_opts.cacertfile' "$RABBITMQ_SSL_CACERTFILE"
rabbit_set_config 'management.listener.ssl_opts.certfile' "$RABBITMQ_SSL_CERTFILE"
rabbit_set_config 'management.listener.ssl_opts.keyfile' "$RABBITMQ_SSL_KEYFILE"

I have added the DN in my definitions.json file:

{
  "global_parameters": [
    {
      "name": "cluster_name",
      "value": "rabbit@omsf"
    }
  ],
  "users": [
    {
      "name": "CN=omsf,OU=Webservice,O=MyOrg,C=DE",
      "tags": "administrator"
    }
  ],
  "vhosts": [
    {
      "name": "/"
    }
  ],
  "permissions": [
    {
      "user": "CN=omsf,OU=Webservice,O=MyOrg,C=DE",
      "vhost": "/",
      "configure": ".*",
      "write": ".*",
      "read": ".*"
    }
  ]
}

At startup in the logs I can see the user "CN=omsf,OU=Webservice,O=MyOrg,C=DE" was created.

When I browse to the management page I'm getting asked to present a certificate. After I select the correct certificate I'm forwarded to the login page. This is weird, because I have disabled all authentication methods, but EXTERNAL in the advanced.config:

{rabbit, [
    {auth_mechanisms, ['EXTERNAL']},
    {tcp_listeners, []}
  ]}

I also tried to add the auth_mechanism to the rabbit_management in the advanced.config:

{rabbitmq_management, [
    {auth_mechanisms, ['EXTERNAL']}
  ]}

Without success.

Versions:

RABBITMQ_VERSION=3.7.7

ERLANG_VERSION=21.0.4

And the important parts of rabbitmqctl environment:

{rabbitmq_management,
    [{auth_mechanisms,['EXTERNAL']},
     {cors_allow_origins,[]},
     {cors_max_age,1800},
     {http_log_dir,none},
     {listener,
         [{ssl_opts,
              [{keyfile,"/opt/ssl/server/oms_server.key"},
               {depth,2},
               {certfile,"/opt/ssl/server/oms_server.cer"},
               {cacertfile,"/opt/cacerts/cacerts.pem"},
               {fail_if_no_peer_cert,true},
               {verify,verify_peer},
               {versions,['tlsv1.2']}]},
          {ssl,true},
          {port,15671}]},
     {load_definitions,"/etc/rabbitmq/definitions_nonprod.json"},
     {management_db_cache_multiplier,5},
     {process_stats_gc_timeout,300000},
     {stats_event_max_backlog,250}]},

{rabbit,
    [{auth_backends,[rabbit_auth_backend_internal]},
     {auth_mechanisms,['EXTERNAL']},

Thank you and best regards,

Roberto

[Luke Bakken]

Hi Roberto,

Did you enable the rabbitmq_auth_mechanism_ssl plugin? That plugin is required for AMQP clients to authenticate using X509 certificates. The rabbitmq_management plugin configuration does not recognize auth_mechanisms so you can remove that.

As far as I know, at this time the management web /ui interface only supports username / password authentication. I believe that the REST API might support X509 certificate authentication, but you may have to pass the DN from the certificate as the user name as the user name of the request, something like

curl --user 'CN=omsf,OU=Webservice,O=MyOrg,C=DE' --cert /path/to/client_certificate.pem --cacert /path/to/server_ca_cert.pem my-rabbit-server:15672/api/aliveness-test/%2F

I don't think anyone has requested this feature nor tried it, so it would be great if you could report back with what you find.

Thanks,

Luke

[Rob A.]

Hi Luke,

Yes, I enabled the plugin. The X509 authentication for amqp clients works with the same user/certificate.

I tried to access the API, but it is still asking for a password (I think otherwise it would be a security issue if you can switch the user):

Enter host password for user 'CN=omsf,OU=Webservice...

I just found an older thread: https://groups.google.com/forum/#!topic/rabbitmq-users/OPxFor_okxw

In our company we have the same security guideline: no user / password logins for these use cases.

All users have a client certificate in their windows account to identify themselve on intrantet applications.

And another thread: https://stackoverflow.com/questions/44172937/certificate-based-authentication-in-rabbitmq-management-plugin

Is it possible to open to create an issue in github for this?

Thank you,

Roberto

[Luke Bakken]

Hi Rob,

The "Enter host password" output is a message from curl, you may be able to get around it by supplying an empty password like this (note the colon at the end of the argument to --user):

curl --user 'CN=omsf,OU=Webservice,O=MyOrg,C=DE:' 

If that doesn't work, try leaving out the --user argument altogether.

If you would like to open an issue in GitHub, this is the correct repository:

https://github.com/rabbitmq/rabbitmq-management

Please ensure that the issue is complete, describing your use case, what you have tried, what isn't working, and provides configuration along with it.

At this point my "feeling" (no guarantees) is that supporting X509 certificate authentication in the REST / HTTP API may be possible. It is less likely to be supported in the Management UI unless someone can provide example code of how to do it via javascript. Here is the code that does login:

https://github.com/rabbitmq/rabbitmq-management/blob/5ec21d188bca010ad61655dd4b791b1df5b6615e/priv/www/js/main.js#L61-L102

If a method to detect the presence of a user-provided X509 certificate to take a different code path could be provided here, then I believe we could be in luck.

Thanks,

Luke

[Luke Bakken]

Hi Rob,

I have done some research and as I suspected, client certificate authentication is not supported by the management plugin (HTTP UI or API).

I have attached the configuration file I used to test. Notice that this setting is in place for AMQP and HTTP connections:

          {verify, verify_peer},

          {fail_if_no_peer_cert, true},

This means that client certificates will be required and will be verified to have been signed by the root CA cert pointed to by cacertfile. So, in the case of the management UI and API, this will require a client certificate to be presented. Users and passwords for those certs will have to be created in RabbitMQ in much the same way that you must to establish permissions for client-cert authorized AMQP connections.

rabbitmqctl add_user 'CN=shostakovich' 'test1234'

rabbitmqctl set_user_tags 'CN=shostakovich' management

rabbitmqctl set_permissions 'CN=shostakovich' '.*' '.*' '.*'

Then, the following curl command worked:

curl -4vvv --cert "$HOME/development/michaelklishin/tls-gen/basic/result/client_certificate.pem" --key "$HOME/development/michaelklishin/tls-gen/basic/result/client_key.pem" --cacert "$HOME/development/michaelklishin/tls-gen/basic/result/ca_certificate.pem" 'https://CN=shostakovich:test1234@localhost:15671/api/overview'

In practice, you could use the same user/password for all client-cert authenticated requests, for instance. The following request fails since no client certificate is presented:

$ curl -4vvv --cacert "$HOME/development/michaelklishin/tls-gen/basic/result/ca_certificate.pem" 'https://CN=shostakovich:test1234@localhost:15671/api/overview'*   Trying 127.0.0.1...

* TCP_NODELAY set

* Connected to localhost (127.0.0.1) port 15671 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /home/lbakken/development/michaelklishin/tls-gen/basic/result/ca_certificate.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Request CERT (13):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Certificate (11):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Client hello (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS alert, Server hello (2):

* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

* stopped the pause stream!

* Closing connection 0

curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

So, in short, it would be nice to read the username from the client cert's CN= value and not require a password, but that feature would have to be requested more frequently to justify implementing it. Even if it were supported, you would have to add users matching the CN= value to RabbitMQ to set their tags and permissions, anyway.

Thanks,

Luke