Skip to content
This repository was archived by the owner on Nov 16, 2020. It is now read-only.

No way to configure client TLS properties #14

Closed
rafaelmagu opened this issue Aug 9, 2018 · 5 comments
Closed

No way to configure client TLS properties #14

rafaelmagu opened this issue Aug 9, 2018 · 5 comments

Comments

@rafaelmagu
Copy link

It appears this plugin cannot connect to a Consul cluster that has been configured to use TLS with self-signed certificates. I cannot supply a CA for it to verify the API certificate against, nor have I found a way to disable hostname verification on the certificate.

I could not find in the codebase a way to supply a client certificate and key for communicating with the Consul HTTP(S) API either.

@rafaelmagu
Copy link
Author

At a minimum, the plugin should support the same set of variables that Consul itself supports: https://www.consul.io/docs/commands/index.html#environment-variables

@michaelklishin michaelklishin changed the title No support for clusters with self-signed TLS certificates No way to configure client TLS properties Aug 9, 2018
@michaelklishin
Copy link
Contributor

michaelklishin commented Aug 9, 2018

There is nothing special about self-signed certificates. Just like with other protocols and plugins such as Shovel or Federation, this plugin simply has to specify TLS client configuration. Since it is built on the most standard built-in HTTP client, httpc, and it relies on Erlang's ssl application configuration, it is possible to do that without any changes to the code.

If we modify the Erlang client example from the RabbitMQ's main TLS guide to put its TLS options into the advanced.config file:

[{ssl, [
           {cacertfile, "/path/to/testca/cacert.pem"},
           {certfile, "/path/to/client/cert.pem"},
           {keyfile, "/path/to/client/key.pem"},

           %% only necessary with intermediate CAs
           %% {depth, 2},

           %% Note: it is recommended to set 'verify' to
           %% to 'verify_peer' to ensure that X509
           %% certificate chain verification is enabled
           %%
           %% Do not set 'verify' or set it to verify_none
           %% if x509 certificate chain verification is
           %% not desired
           {verify, verify_peer},

           %% If Server Name Indication validation is desired,
           %% set the following option to the host name to which
           %% the connection is made. If necessary, this option
           %% may be set to another host name to match the server
           %% certificate's CN= value.
           %% Do not set this option or set it to the atom 'disable'
           %% to disable SNI validation
           {server_name_indication, disable}
  ]}

%% , {rabbit. [
%% ...
%% ]}
].

@dpresling
Copy link

Does this mean I have to use the same certificate for Rabbit TLS as I do for Consul?

@michaelklishin
Copy link
Contributor

It absolutely doesn't. All it means that the client has to provide its certificate/key pair and a set of TLS options (most of which are optional and include peer verification, cipher suites the client agrees to use, verification depth, SNI target and so on). Which is a bit more involved than with Consul at the moment but not impossible.

@michaelklishin
Copy link
Contributor

Our team does not use GitHub issues for discussions. Please direct all further questions to rabbitmq-users, our public mailing list, and watch the two issues above if you are interested in future improvements (including to the docs).

@rabbitmq rabbitmq locked and limited conversation to collaborators Apr 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants