Support for Mutual TLS when using RabbitMQ

[gerard-br-dge]

Feature

There is limited SSL/TLS support currently when connecting via RabbitMQ, see Support amqps. However, there are two limitations to the current approach,

1. It hard codes to use a TrustManager that will accept any incoming server certificate and so isn't really appropriate for production environments
2. It hard codes to an empty Key Store. This means that Mutual TLS cannot be supported

However, the com.rabbitmq.client.ConnectionFactory provides an alternate approach that would allow the SSLContext to be created within zipkin-server. This SSLContext could be configured to 'real' Trust & Key Stores, allowing Mutual TLS.

If we have optional properties that can point to the location of trust & key store files and corresponding passwords, then when present, a SSLContext could be built. If these properties were not defined or an error occured on loading then the collector can default to the existing behaviour

Rationale

When integrating with RabbitMQ, this feature has the advantage of removing the potential securiity risk of using a TrustManager that accepts any certificate for RabbitMQ, while providing support for Mutual TLS.

It would be a non-breaking change

Example Scenario

In environments where RabbitMQ is the primary messaging/communication system and Mutual TLS is mandated, it allows zipkin to be used

Prior Art

• Links to prior art
• More links

[codefromthecrypt]

I think this is a continuation of #1827 as that issue wasn't closed. This needs analysis still. There are other transports and storage that can leverage alternate keystore etc, so best to use a coherent approach to this.