You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "matteo rulli (JIRA)" <ji...@apache.org> on 2015/06/29 09:40:04 UTC

[jira] [Created] (AMQ-5867) Refresh SSL context through a custom SslContext implementation

matteo rulli created AMQ-5867:
---------------------------------

             Summary: 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.4#6332)