If someone has unauthorized access to the broker such that they can change
its configuration then he *already* has access to the unencrypted data in
memory and on disk (i.e. in the journal). I see this mainly as a problem
to be solved at one of the many other security layers before the broker is
e
Thanks, Justin.
I'm not entirely convinced there is a real cause for concern here. If the
> broker itself is configured to allow non-SSL traffic when it shouldn't that
> seems like a broker configuration problem. The bottom line is that the
> broker must be configured appropriately. There's only s
> Thus, you would have to pass it in plaintext, e.g. this won't work:
-Dorg.apache.activemq.ssl.keyStorePassword=ENC(...)?
That's correct. Currently neither "org.apache.activemq.ssl.keyStorePassword"
nor "org.apache.activemq.ssl.trustStorePassword" support password masking.
This follows the conve
Hello Community,
This is a follow up to https://issues.apache.org/jira/browse/ARTEMIS-1157
I set up a cluster of Artemis Brokers (2.6.0) with master/slave replication
configuration.
Each broker is configured with:
1. *Acceptor*:
*sslEnabled=true;needClientAuth=true,enabledProtocols=...;enabledCi
