Steps needed to configure Artemis SSL client authentication using trusted CA Certificates

0
votes

According to the ActiveMQ Artemis documents it is possible to do 2 way TLS aka client certificate authentication using a trusted CA. See extract below.

Two-way TLS uses the same sslEnabled, keyStorePath, and keyStorePassword properties as one-way TLS, but it adds needClientAuth=true to tell the client it should present a certificate of its own. For example:

<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true</acceptor>

This configuration assumes that the client's certificate is signed by a trusted provider. If the client's certificate is not signed by a trusted provider (e.g. it is self-signed) then the server needs to import the client's certificate into a trust-store and configure the acceptor with trustStorePath and trustStorePassword, e.g.:

<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!</acceptor>

My requirements at the moment are full 2 way SSL with client getting their cert from our CA. According to the docs my understanding is that we would not need to add the keys of client to the trust store every time a user signs up. NOTE: we are doing this on the AMQP protocol.

On a high level the setup would be:

  1. Install CA into JRE cacerts keystore.
  2. Create a signing request for the broker.
  3. CA creates certificate for broker.
  4. Install broker certificate into keystore (e.g. etc/broker-certs.p12)
  5. Client creates cert signing request
  6. CA creates client certificate.
  7. Client presents certificate when connecting.

Before I go down the rabbit hole of SSL I wanted to check that if what I am trying to achieve is even possible?

I tried the ssl-enabled-dual-authentication example however it is throwing an exception on launch of the client.

Caused by: org.apache.activemq.artemis.api.core.ActiveMQConnectionTimedOutException: AMQ219013: Timed out waiting to receive cluster topology. Group:null

FOR JDK 11+ Users: To try out the ssl-enabled-dual-authenticaion example you will need to recreate all the certificates. The comments sections has some more details.

1
activemq-artemis
You missed configuring needClientAuth=true as well as trustStorePath and trustStorePassword in your self-signed acceptor example. – Justin Bertram
I just ran the ssl-enabled-dual-authentication on the current master branch as well as 2.17.0, 2.16.0, 2.15.0, 2.14.0, 2.13.0, & 2.12.0 and they all completed successfully with no exceptions. Perhaps something in your environment is messed up. – Justin Bertram
Do I need to create an instance before running the examples? I just unzipped it and did a mvn verify. Running on Ubuntu for what it is worth. – Namphibian
You don't need to manually create an instance. Using mvn verify will automatically create any necessary instances. I'm on Ubuntu as well, and I also just unzipped and ran mvn clean verify. – Justin Bertram
I forgot I am running JDK 11 as I am doing camel 3 work and JDK 8 is best effort only. When I ran mvn -Prelease install it reported the following:[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message: JDK 8 is required when building the release. That is ok. I will use the example and run a local instance as I can stay on JDK11 for now. – Namphibian

1 Answers

1
votes

Yes, it's possible, and your "high level" steps look good.

It may be helpful to look at the ssl-enabled-dual-authentication example that ships with the broker. It demonstrates how to configure mutual authentication using self-signed certificates including the keytool commands for creating, importing, & exporting the various SSL resources. This is slightly different than your use-case which involves using a CA, but the process is essentially equivalent. The real difference is that instead of adding the client's cert to the broker's truststore and vice versa you're adding the CA's cert to all the JVMs.