1
votes

When using the rabbitmq_auth_backend_ldap, if we use ssl, is it necessary to mention SSL options to make sure we are talking to the right server, using options such as :

{ssl_options, [ {server_name_indication, "abc.com"},
                    {verify, verify_peer},
                    {depth, 5}]},

Note that I am not interested in doing client certificate authentication to the Ldap server, but only to verify whether I am actually talking to the right server, which cannot be ensured unless I verify the SN or similar from the certificate. Browsers kind of do that automatically, but how does RabbitMQ do this.

If the SSL certificate presented by the server is signed by a trusted root such as GoDaddy or such, should I still mention the certificates that I am trusting.

2

2 Answers

1
votes

I verify the SN or similar from the certificate. Browsers kind of do that automatically, but how does RabbitMQ do this.

Here is the answer to your question.

Every TLS-enabled tool and TLS implementation, including Erlang/OTP and RabbitMQ, has a way of marking a set of certificates as trusted. On Linux and other UNIX-like systems this is usually a directory administered by superusers. CA certificates in that directory will be considered trusted, and so are the certificates issued by them (such as those presented by clients). Locations of the trusted certificate directory will vary between distributions, operating systems and releases

More Info here

If you would like to have your own custom trust store. You can consider below stuff.

https://rabbitmq.docs.pivotal.io/37/rabbit-web-docs/ssl.html#keys-and-certs https://github.com/rabbitmq/rabbitmq-trust-store

-1
votes

So without the below configurations, at a minimum, I feel that the SSL security is not complete for a LDAP setup.
In case of LDAP, the connection is made from the RMQ server(via erlang client) to the LDAP server, so at that point of time the SSL certificates are presented by the LDAP server.

RMQ server(client) -> LDAP server(server)

and Unless the following options are specified, the certificate is not validated.

{servers, ["abc.com"]},
    {timeout, 10000},
    {use_ssl,     true},
    {ssl_options, [ {cacertfile, "/etc/ssl/certs/ca-certificates.crt"},
                    {server_name_indication, "abc.com"},
                    {verify, verify_peer},
                    {depth, 5}]},
    {port, 636}

verify: verify_peer

  • indicates that we prefer the certificate chain to be verified
  • will be verified that the certificate chain terminates from one of the trusted certificates mentioned in cacertfile.

cacertfile

  • will point to the certificates to trust.
  • It can be pointed to a file which contains a list of trusted certificates in ---Begin Certificate--- ---End Certificate-- format
  • If the LDAP servers certificates are signed by trusted root certifcates we can point this variable to /etc/ssl/certs/ca-certificates.crt.
  • If the server certificates are self signed then point to a file containing appropriate certificates.

server_name_indication:abc.com

  • this enforces that this is just not some server we are talking to but only abc.com
  • will verify that the server certificates SN has abc.com.

depth:

  • this indicates the number of certificates in the certificate chain that we will traverse before it needs to terminate into one of the trusted certificates we have.
  • keep this a bigger number than the no of certs in your servers cert chain

This is without any client cert authentication between the LDAP server and the RMQ server.