[
https://issues.apache.org/jira/browse/ARTEMIS-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated ARTEMIS-1888:
--------------------------------------------
Description:
When doing some testing I noticed that the order of precedence for setting SSL
properties inside the core client NettyConnector is a bit backwards. Any
javax.ssl property takes ultimate precedence and overrides a property that is
set locally in the configuration map. This doesn't make sense to me and makes
it so you can't override settings (ie in the same JVM have two different
connections use different SSL settings if a global javax.ssl property is
already set). There is a comment that mentions HORNETQ-680 as where this
change was made so. I'm not sure what side effects this will have but I think
this behavior is wrong and doesn't match how the 5.x client works.
To fix this without breaking existing users, a new flag can be added called
{{forceSSLParameters}} which will signal to prefer local SSL settings over any
system property.
was:
When doing some testing I noticed that the order of precedence for setting SSL
properties inside the core client NettyConnector is a bit backwards. Any
javax.ssl property takes ultimate precedence and overrides a property that is
set locally in the configuration map. This doesn't make sense to me and makes
it so you can't override settings (ie in the same JVM have two different
connections use different SSL settings if a global javax.ssl property is
already set). There is a comment that mentions HORNETQ-680 as where this
change was made so. I'm not sure what side effects this will have but I think
this behavior is wrong and doesn't match how the 5.x client works.
I think that the order of precedence should be changed to the following when
looking for SSL properties:
# First check the transport configuration for a property setting
# If not set then next check for an ActiveMQ specific JVM property
# If not set then check for a javax.ssl JVM wide property
# Lastly, if still not set then use a default value (in the case of the
keystore or truststore provider)
> Add forceSSLParameters flag to core client to prefer local SSL properties
> over System properties
> ------------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-1888
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1888
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.6.0
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Priority: Major
> Fix For: 2.7.0
>
>
> When doing some testing I noticed that the order of precedence for setting
> SSL properties inside the core client NettyConnector is a bit backwards. Any
> javax.ssl property takes ultimate precedence and overrides a property that is
> set locally in the configuration map. This doesn't make sense to me and
> makes it so you can't override settings (ie in the same JVM have two
> different connections use different SSL settings if a global javax.ssl
> property is already set). There is a comment that mentions HORNETQ-680 as
> where this change was made so. I'm not sure what side effects this will have
> but I think this behavior is wrong and doesn't match how the 5.x client works.
> To fix this without breaking existing users, a new flag can be added called
> {{forceSSLParameters}} which will signal to prefer local SSL settings over
> any system property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
