ARTEMIS-5163 Broker fails to send mqtt will message using mutual TLS

[JeanLucGraphalo]

Implements a fix of bug ARTEMIS-5163.

The client's certificate is cached in order to successfully authenticate when sending LWT using mutual TLS.

• cache X509Certificate in RemotingConnection
• try to get certificate from channel if not already cached (CertificateUtil)

[jbertram]

Thanks for the PR!

[jbertram]

There appears to be an issue with the test. The wss version succeeds, but the ssl version does not. It appears that the invocation of org.eclipse.paho.mqttv5.client.MqttClient#disconnectForcibly(long, long, boolean) in the latter does not trigger the broker to send the will message because the broker doesn't recognize that the willSender client has disconnected.

Do you see this same behavior when you run the test?

[JeanLucGraphalo]

I ran the tests on my local machine and both (wss and ssl) succeeded.

The approach of calling org.eclipse.paho.mqttv5.client.MqttClient#disconnectForcibly(long, long, boolean) to trigger LWT was copied from org.apache.activemq.artemis.tests.integration.mqtt5.MQTT5Test. Is there probably any parameter to be tuned that makes the test more robust?

Do you see the same behavior when you change the parameterization to run only the ssl version?

[jbertram]

Do you see the same behavior when you change the parameterization to run only the ssl version?

Yes.

All things being equal, using disconnectForcibly is reasonable. However, in this particular case it seems to be problematic.

[JeanLucGraphalo]

I tried to reproduce the test error and it seems that the latch countdown is slightly too low. Does the test run successfully with increased value (from 2 to 3 seconds)?

[jbertram]

Does the test run successfully with increased value (from 2 to 3 seconds)?

No. I even increased it to 30 and it still failed.

In any case, you can work-around the issue like so:

      if (protocol.equals(WSS)) {
         willSender.disconnectForcibly(0, 0, false);
      } else {
         // for some reason disconnectForcibly doesn't work in this case so we trick the broker into sending the LWT
         getSessionStates().get(willSenderId).setFailed(true);
         getSessionStates().get(willSenderId).setAttached(false);
      }

[JeanLucGraphalo]

I added the workaround. Thanks!

[JeanLucGraphalo]

I've moved CertificateUtil to artemis-server. Now it is possible to cache the certificates directly in the NettyServerConnection. This makes the recent changes irrelevant.

[gemmellr]

LGTM and passed the full test suite. I'll leave for Justin to merge to check he is happy too.

[jbertram]

@JeanLucGraphalo, nice work! Thanks for the contribution.