[
https://issues.apache.org/jira/browse/AMQ-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15867664#comment-15867664
]
Gary Tully commented on AMQ-5867:
---------------------------------
[~thodimi] that seems sensible however it may be better to have the
possibility to dot sslContext config where it is needed. I think there is
always separation between the socketFactory and serverSocketFactory usage.
ie: for a networkConnector it will be a client, a transportConnector will be a
server etc.
If we move away from the thread local, which is implicitly shared, it can be
possible to have separate sslContext conf and it will be easier to support
reloading etc.
So add sslContext to networkConnector and you will have full control if the ssl
client connection needs to do establish trust.
> Refresh SSL context through a custom SslContext implementation
> --------------------------------------------------------------
>
> Key: AMQ-5867
> URL: https://issues.apache.org/jira/browse/AMQ-5867
> Project: ActiveMQ
> Issue Type: Improvement
> Affects Versions: 5.10.0
> Reporter: matteo rulli
>
> The scenario is the following:
> {code}
> BrokerService broker = new BrokerService();
> // ... many config options ...
> SslContext customSslContext = getCustomSslContext();
> broker.setSslContext(customSslContext);
> // ... start the broker
> {code}
> where getCustomSslContext() returns a custom implementation of SslContext
> that allows reloading the truststore when a new certificate is available.
> In the
> _org.apache.activemq.transport.nio.NIOSSLTransportFactory.createSocketFactory()_
> method, one sees that the _SslContext.getCurrentSslContext()_ always returns
> null: this is due to the fact that _org.apache.activemq.broker.SslContext_
> has two different ssl contexts management: the first one based on static
> ThreadLocal _current_ variable and the other one based on non-static
> _sslContext_ variable.
> Apparently, it is possible to refresh the latter but not the first one.
> Unfortunately, the _NIOSSLTransportFactory.createSocketFactory()_ uses the
> _current_ variable: as a result the new certificate managed by
> _customSslContext_ is never used in the ssl handshake.
> ----
> Gary Tully commented on that in [this
> thread|http://activemq.2283324.n4.nabble.com/Rfresh-org-apache-activemq-broker-SslContext-from-disk-jks-content-tp4698040p4698164.html]:
> {quote}
> it is a limitation. the thread local allows the different connectors
> to find the brokers context, so that network connector and discovered
> transports can find an appropriate context.
> This makes it simple to configure (broker wide) but difficult to
> modify and difficult to have per endpoint ssl options.
> The connectors and ssl factories need to be be refactored to have
> their own sslcontext and only delegate to the broker context in the
> absence of a specialisation.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
