[
https://issues.apache.org/jira/browse/ARTEMIS-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16010706#comment-16010706
]
Justin Bertram commented on ARTEMIS-1157:
-----------------------------------------
bq. Imagine a broker sets in the cluster-connector - lets say one or two cipher
suites with the property: enabledCipherSuites=TLS_AES_WITH... Now if the
clients JRE - for whatever reason - does not support that cipher suite (JRE to
old, disabled in JRE security settings, JRE from vendor that does not support
it at all...) In that case, the initial connection from the client will work,
but as soon as a failover occurs, client connection fails.
Couple of things:
- What's the use-case where you'd want to set {{enabledCipherSuites}} on a
connector and _not_ set it on the corresponding acceptor?
- What's the use-case where different cluster nodes would support different
cipher suites.
I understand both of these use-cases are technically possible, but at this
point they don't make sense to me so I'm not inclined to consider them worth
supporting.
bq. Another thing is: clientA -> HA-brokerA -> Bridge -> HA-brokerB -> clientB.
This is a simple setup but consists out of 4 independent components and each
component is high-available so in the most basic case this will result in 8
Boxes (VM's, containers, whatever...).
I'm confused about this use-case. I assume the "4 independent components" here
are clientA, HA-brokerA, HA-brokerB, & clientB. I don't understand how that
results in 8 boxes since typically only the brokers would consist of a
live/backup pair. Also, is the "Bridge" a cluster bridge (which is
automatically configured by the internal cluster manager) or a bridge defined
in broker.xml explicitly?
bq. Configuring all this systems in a consistent way in large organisations can
be challenging. Because if just one component is configured the wrong way,
initially everything works but as soon as a failover occurs, the system stops
working.
As long as the brokers are configured consistently (which is the
recommendation), for example using the same value for enabledCipherSuites on
their acceptors, then any client that can't connect to the backup will also
fail to connect to the live.
bq. I just want to highlight here, that the current concept can be
"complicated/intransparent"...
The SSL use-case here certainly isn't the most elegant, but given the broker's
clustering design I can't think of anything better at this point (and I'm not
convinced I need to at this point).
bq. This will also require a lot of testing every time you change something.
I think this is a bit of an overstatement. As stated before, the recommendation
is for all cluster nodes to be configured equivalently. If that recommendation
is followed then I think you can avoid most of the issues you've identified
here. Transparent/automatic functionality like fail-over and connection
load-balancing assumes equivalent configuration between nodes. I believe this
is the case for most software that provides similar functionality.
> Do not update ssl client keystore/truststore path on topology update
> --------------------------------------------------------------------
>
> Key: ARTEMIS-1157
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1157
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Reporter: Philipp Aeschlimann
> Attachments: ArtemisMqCrashDemoClient.java, broker.xml
>
>
> We have a 2 node cluster where clients and the refrenced connectors in the
> cluster-connection do use ssl client auth (all working so far). Now if a
> failover ocures - live server goes down - the clients try to re-connect with
> the client keystore path that is defined on the connector in the server.
> We know that it is possible to overwrite this behavoir by using
> org.apache.activemq.ssl.keyStore system property. But we have multiple
> keystores and want to use them. Would it be possible, that this settings:
> org.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants.KEYSTORE_*
> org.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants.TRUSTSTORE_*
> will not be updated from the server? I can not think of a scenario, where it
> would make sense that the server tells the client where the client has to
> look for his keystore and truststore settings.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
