Very old thread - but just in case someone comes accross this!
SSLContext ctx = SSLContext.getInstance("TLS"); // for nio
ctx.init(getKeyManager(), getTrustManager(), new SecureRandom());
SSLContext.setDefault(ctx);
Note javax.net.ssl.SSLContext and NOT org.apache.activemq.broker.SslContext
-
On Jan 5, 2012, at 2:58 AM, Dejan Bosanac wrote:
>> Why then do the NIO[SSL]* bits even have methods with *SocketFactory bits,
>> is this due to extending the TCP bits?
>
> It's used on the client side to create socket.
I thought the client-side was expected to use the regular ssl transport?
>
>
>
> Why then do the NIO[SSL]* bits even have methods with *SocketFactory bits,
> is this due to extending the TCP bits?
>
It's used on the client side to create socket.
>
> What is the NIO version of the SslSocketFactory muck? (I know jack about
> nio, only that it exists and uses buffers an
On Jan 4, 2012, at 5:41 AM, Dejan Bosanac wrote:
> nio+ssl should work exactly the same as the plain ssl transport, so this
> SslBrokerService enhancement you're working is totally valid and we should
> have it.
Okay I think I can make a simple test to show working ssl and non-working
nio+ssl the
Sv1 ALERT: fatal, description =
> handshake_failure
> > ActiveMQ Task-2, WRITE: TLSv1 Alert, length = 2
> > ActiveMQ Task-1, fatal: engine already closed. Rethrowing
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> > ...
> >
> >
> > R
correctly and the
> test behaves as expected wrt clientAuth, etc.
>
> I was digging around a little, and I'm not really sure if this is correct...
> but it does not look like the nio+ssl transport server is getting the ssl
> serversocke
ning the *exact same test* changing only the brokers transport scheme
> from "nio+ssl" to "ssl" and the ssl connection is established correctly and
> the test behaves as expected wrt clientAuth, etc.
>
> I was digging around a little, and I'm not really sure if this is
> correct... but it do
