[
https://issues.apache.org/jira/browse/ARTEMIS-3081?focusedWorklogId=543873&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-543873
]
ASF GitHub Bot logged work on ARTEMIS-3081:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jan/21 20:45
Start Date: 28/Jan/21 20:45
Worklog Time Spent: 10m
Work Description: inkarkat commented on pull request #3416:
URL: https://github.com/apache/activemq-artemis/pull/3416#issuecomment-769377822
> [...] if you set both the javax.ssl.* and org.apache.activemq.ssl.* system
properties currently, the latter will surprisingly be ignored and not do
anything. That makes those properties useless a lot of the time [...]
Exactly. In virtually every configuration mechanism I've encountered so far,
the application-specific one would override the more general one, not the other
way around. It is really unexpected that the precedence is reversed in Artemis.
Apart from that, I'd like to mention that using the suggested
`forceSSLParameters` is less convenient in our case, as the actual
instantiation of the `NettyConnector` is not directly done in our own code, but
by JBoss. Now, there's likely a way to pass additional configuration in there
(e.g. through configuration file or subclassing), but it's not as
straightforward as setting the Java property (as part of the JBoss
bootstrapping, which is what we're doing right now).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 543873)
Time Spent: 1.5h (was: 1h 20m)
> Cannot override the default Java key/truststore properties
> ----------------------------------------------------------
>
> Key: ARTEMIS-3081
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3081
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.15.0, 2.17.0
> Environment: In our case the application uses the default Java
> truststore location at {{$JAVA_HOME/lib/security/jssecacerts}}, and only
> supplies its password in {{javax.net.ssl.trustStorePassword}}, and then uses
> a dedicated truststore for Artemis. Defining both
> {{org.apache.activemq.ssl.trustStore}} and
> {{org.apache.activemq.ssl.trustStorePassword}} now makes Artemis use the
> dedicated truststore ({{javax.net.ssl.trustStore}} is not set as we use the
> default location, so the second choice
> {{org.apache.activemq.ssl.trustStore}} applies), but with the Java default
> truststore password (first choice {{javax.net.ssl.trustStorePassword}}
> applies instead of the second choice because it is set for the default
> truststore). Obviously, this does not work unless both passwords are
> identical!
> Reporter: Ingo Karkat
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If an application wants to use a special key/truststore for Artemis but have
> the remainder of the application use the default Java store, the
> {code:java}
> org.apache.activemq.ssl.keyStore{code}
> needs to take precedence over Java's
> {code:java}
> javax.net.ssl.keyStore{code}
> However, the current implementation takes the first non-null value from
> {code:java}
> System.getProperty(JAVAX_KEYSTORE_PATH_PROP_NAME)
> System.getProperty(ACTIVEMQ_KEYSTORE_PATH_PROP_NAME)
> keyStorePath{code}
> So if the default Java property is set, no override is possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
