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

["Murali Mogalayapalli (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861468#comment-15861468 ] 

Murali Mogalayapalli commented on AMQ-5867:
-------------------------------------------

[~gtully] I have the need to support Networkconnector ( Network connector needs to use SSL client authentication ). This is not working because the sslcontext is being shared between the serverfactory and client factory and there is no way to tell the java ssl api to use a specific key for the server socket. I am thinking of the following changes

Enhance the SSLContext to enable two stores one for server another one  for other uses namely Networkconntector.
<sslContext>
            <sslContext keyStore="file:${activemq.conf}/broker.jks"   keyStorePassword="test" trustStore="file:${activemq.conf}/broker.ts" trustStorePassword="test" 
			serverKeyStore="file:${activemq.conf}/broker-server.jks"   serverKeyStorePassword="test" serverTrustStore="file:${activemq.conf}/broker.ts" serverTrustStorePassword="test" 

	/>
	
If the server store is not configured use the default store. This preserves the backward compatibility. 
Enahnce the sslContext class to handle both stores appropriately.

Let me know your thoughts
Thanks
-MM

	 
        </sslContext>	

> 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)