You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Gary Tully <ga...@gmail.com> on 2009/03/26 23:21:06 UTC
Re: Alternatives for deprecated setKeyAndTrustManagers in
ActiveMQSSLConnectionFactory
An ActiveMQ ssl client is just like an other java application that wants to
use ssl. Configuration is through JSSE.
The ActiveMQ SSLContext is just a thread specific holder for a regular
SSLContext, if no context is specified the platform default (from JSSE) will
be used. The thread specific nature allows different credentials to be used
in the same JVM. If individual contexts are not required, then configure
JSSE at the JVM level and ActiveMQ will pick up the default socket factory
and work with it.
So you are on the right track, if you want to programmaticly specify the
JSSE credentials and stores, pass the arguments to an instance of
SSLContext.
If you want to remain JMS agnostic, then you should stick to the raw JSSE
apis.
What restrictions does: "as our's is an enterprise application." imply?
And that deprecated of setKeyAndTrustManagers, I will remove that as it is a
handy method and it no longer sets up shared credentials, it just sets a
current context using the thread local.
The alternative is to construct an ActiveMQ SSLContext wrapper and use its
setters and call getSSLContext or just use raw JSSE SSLContext.
2009/3/26 soody <at...@gmail.com>
>
> We want to use SSL in our client that will be sending messages to ActiveMQ.
> But we can't set the trust stores and key stores using
> System.setProperty(),
> as our's is an enterprise application.
>
> Are there any ways that I can set the trust and key stores, basically the
> SSLContext. Currently what we are thinking is that we will be using the
> SSLContext.setCurrentSslContext(<will create a context using JSSE and dump
> it here>).
>
> Is there any better approach. Also will be great if we can get anything
> more
> pluggable, s.th that we can use across multiple JMS providers.
>
> Also why is the method setKeyAndTrustManagers marked as deprecated and
> what
> is the workaround for the same.
> --
> View this message in context:
> http://www.nabble.com/Alternatives-for-deprecated-setKeyAndTrustManagers-in-ActiveMQSSLConnectionFactory-tp22724170p22724170.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source SOA
http://FUSESource.com
Re: Alternatives for deprecated setKeyAndTrustManagers in
ActiveMQSSLConnectionFactory
Posted by soody <at...@gmail.com>.
Thanks Gary for the suggestions.
I was able to get a working code. Sharing the same for review as well as for
others.
ConnectionFactory factory = (ConnectionFactory) ctx.lookup(FACTORY_NAME);
System.out.println("Lookup succesfull " + factory.toString());
System.setProperty("javax.net.debug",
"ssl,handshake,data,trustmanager");
try {
TrustManager[] tms=getTrustManagers();
KeyManager[] kms=getKeyManagers();
SSLContext context=SSLContext.getInstance("SSL");
context.init(kms, tms, null);
SslContext ctxt = new SslContext();
ctxt.setSSLContext(context);
SslContext.setCurrentSslContext(ctxt);
} catch (NoSuchAlgorithmException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
private static TrustManager[] getTrustManagers()
throws IOException, GeneralSecurityException
{
// First, get the default TrustManagerFactory.
String alg=TrustManagerFactory.getDefaultAlgorithm();
TrustManagerFactory tmFact=TrustManagerFactory.getInstance(alg);
FileInputStream fis=new FileInputStream("location of trust store");
KeyStore ks=KeyStore.getInstance("jks");
ks.load(fis, "password".toCharArray());
fis.close();
tmFact.init(ks);
// And now get the TrustManagers
TrustManager[] tms=tmFact.getTrustManagers();
return tms;
}
private static KeyManager[] getKeyManagers()
throws IOException, GeneralSecurityException
{
// First, get the default KeyManagerFactory.
String alg=KeyManagerFactory.getDefaultAlgorithm();
KeyManagerFactory kmFact=KeyManagerFactory.getInstance(alg);
FileInputStream fis=new FileInputStream("location of key store");
KeyStore ks=KeyStore.getInstance("jks");
ks.load(fis, "password".toCharArray());
fis.close();
// Now we initialise the KeyManagerFactory with this KeyStore
kmFact.init(ks, "password".toCharArray());
// And now get the KeyManagers
KeyManager[] kms=kmFact.getKeyManagers();
return kms;
}
Thanks again for the help.
Gary Tully wrote:
>
> Just looked at SslTransportFactory.setKeyAndTrustManagers again, it makes
> sense to deprecate because this api used to set the sslcontext for the
> factory. It is now changed in line with the use of thread local but the
> api
> for setting the thread local is SSLContext.setCurrentContext.
>
> So the behavior has changed to keep it in line with the use of a thread
> local but the intention of setting a context on the factory is
> depreciated.
> I added a @see reference to SSLContext.
>
>
> 2009/3/26 Gary Tully <ga...@gmail.com>
>
>> An ActiveMQ ssl client is just like an other java application that wants
>> to
>> use ssl. Configuration is through JSSE.
>> The ActiveMQ SSLContext is just a thread specific holder for a regular
>> SSLContext, if no context is specified the platform default (from JSSE)
>> will
>> be used. The thread specific nature allows different credentials to be
>> used
>> in the same JVM. If individual contexts are not required, then configure
>> JSSE at the JVM level and ActiveMQ will pick up the default socket
>> factory
>> and work with it.
>>
>> So you are on the right track, if you want to programmaticly specify the
>> JSSE credentials and stores, pass the arguments to an instance of
>> SSLContext.
>>
>> If you want to remain JMS agnostic, then you should stick to the raw JSSE
>> apis.
>>
>> What restrictions does: "as our's is an enterprise application." imply?
>>
>> And that deprecated of setKeyAndTrustManagers, I will remove that as it
>> is
>> a handy method and it no longer sets up shared credentials, it just sets
>> a
>> current context using the thread local.
>> The alternative is to construct an ActiveMQ SSLContext wrapper and use
>> its
>> setters and call getSSLContext or just use raw JSSE SSLContext.
>>
>>
>> 2009/3/26 soody <at...@gmail.com>
>>
>>
>>> We want to use SSL in our client that will be sending messages to
>>> ActiveMQ.
>>> But we can't set the trust stores and key stores using
>>> System.setProperty(),
>>> as our's is an enterprise application.
>>>
>>> Are there any ways that I can set the trust and key stores, basically
>>> the
>>> SSLContext. Currently what we are thinking is that we will be using the
>>> SSLContext.setCurrentSslContext(<will create a context using JSSE and
>>> dump
>>> it here>).
>>>
>>> Is there any better approach. Also will be great if we can get anything
>>> more
>>> pluggable, s.th that we can use across multiple JMS providers.
>>>
>>> Also why is the method setKeyAndTrustManagers marked as deprecated and
>>> what
>>> is the workaround for the same.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Alternatives-for-deprecated-setKeyAndTrustManagers-in-ActiveMQSSLConnectionFactory-tp22724170p22724170.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> http://blog.garytully.com
>>
>> Open Source SOA
>> http://FUSESource.com
>>
>
>
>
> --
> http://blog.garytully.com
>
> Open Source SOA
> http://FUSESource.com
>
>
--
View this message in context: http://www.nabble.com/Alternatives-for-deprecated-setKeyAndTrustManagers-in-ActiveMQSSLConnectionFactory-tp22724170p22741202.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Alternatives for deprecated setKeyAndTrustManagers in
ActiveMQSSLConnectionFactory
Posted by Gary Tully <ga...@gmail.com>.
Just looked at SslTransportFactory.setKeyAndTrustManagers again, it makes
sense to deprecate because this api used to set the sslcontext for the
factory. It is now changed in line with the use of thread local but the api
for setting the thread local is SSLContext.setCurrentContext.
So the behavior has changed to keep it in line with the use of a thread
local but the intention of setting a context on the factory is depreciated.
I added a @see reference to SSLContext.
2009/3/26 Gary Tully <ga...@gmail.com>
> An ActiveMQ ssl client is just like an other java application that wants to
> use ssl. Configuration is through JSSE.
> The ActiveMQ SSLContext is just a thread specific holder for a regular
> SSLContext, if no context is specified the platform default (from JSSE) will
> be used. The thread specific nature allows different credentials to be used
> in the same JVM. If individual contexts are not required, then configure
> JSSE at the JVM level and ActiveMQ will pick up the default socket factory
> and work with it.
>
> So you are on the right track, if you want to programmaticly specify the
> JSSE credentials and stores, pass the arguments to an instance of
> SSLContext.
>
> If you want to remain JMS agnostic, then you should stick to the raw JSSE
> apis.
>
> What restrictions does: "as our's is an enterprise application." imply?
>
> And that deprecated of setKeyAndTrustManagers, I will remove that as it is
> a handy method and it no longer sets up shared credentials, it just sets a
> current context using the thread local.
> The alternative is to construct an ActiveMQ SSLContext wrapper and use its
> setters and call getSSLContext or just use raw JSSE SSLContext.
>
>
> 2009/3/26 soody <at...@gmail.com>
>
>
>> We want to use SSL in our client that will be sending messages to
>> ActiveMQ.
>> But we can't set the trust stores and key stores using
>> System.setProperty(),
>> as our's is an enterprise application.
>>
>> Are there any ways that I can set the trust and key stores, basically the
>> SSLContext. Currently what we are thinking is that we will be using the
>> SSLContext.setCurrentSslContext(<will create a context using JSSE and dump
>> it here>).
>>
>> Is there any better approach. Also will be great if we can get anything
>> more
>> pluggable, s.th that we can use across multiple JMS providers.
>>
>> Also why is the method setKeyAndTrustManagers marked as deprecated and
>> what
>> is the workaround for the same.
>> --
>> View this message in context:
>> http://www.nabble.com/Alternatives-for-deprecated-setKeyAndTrustManagers-in-ActiveMQSSLConnectionFactory-tp22724170p22724170.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> http://blog.garytully.com
>
> Open Source SOA
> http://FUSESource.com
>
--
http://blog.garytully.com
Open Source SOA
http://FUSESource.com