How to use default SSL TrustStore/KeyStore loading and trust behavior - getting no cipher suites in common
Mathew Johnston
mjohnston at capsaicin.ca
Mon Jan 10 20:05:04 EST 2011
Hi Marc, thanks for the attention.
I never did figure out why this didn't work. I reverted back to manually
instantiating my keystores and instantiating KeyManagers and TrustManagers
as the Netty example code does (this works). To anyone else having the same
problem, here's what I basically ended up with:
TrustManagerFactory tmFactory = TrustManagerFactory.getInstance("PKIX");
KeyStore tmpKS = null;
tmFactory.init(tmpKS);
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new
FileInputStream(System.getProperty("javax.net.ssl.keyStore")),
System.getProperty("javax.net.ssl.keyStorePassword").toCharArray());
// Set up key manager factory to use our key store
KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
kmf.init(ks,
System.getProperty("javax.net.ssl.keyStorePassword").toCharArray());
KeyManager[] km = kmf.getKeyManagers();
TrustManager[] tm = tmFactory.getTrustManagers();
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(km, tm, null);
SSLEngine engine = sslContext.createSSLEngine();
And this works just fine.
2010/11/29 Marc-André Laverdière <marcandre.laverdiere at gmail.com>
> Hi,
>
> I don't see any problems with the code itself... only that you are
> using the system-default keystore and trust store. That is not wrong
> in itself, but I don't think of that as scaling smoothly if you have
> multiple applications running on the same machine.
>
> The problem is not netty-specific, it has everything to do with the
> SSL implementation in Java.
>
> Which keys are you using, RSA or DH/DHE? Are you on TLSv1 or SSLv3?
> What is the client's SSL library?
>
> I remember that, in my case, after disabling all the weak(er) suites,
> I was down to only one possible option!!! It might be something
> similar for you, and the other side maybe doesn't support it.
>
> Regards,
>
> Marc-André LAVERDIÈRE
> "Perseverance must finish its work so that you may be mature and
> complete, not lacking anything." -James 1:4
> http://asimplediscipleslife.blogspot.com/
> mlaverd.theunixplace.com
>
>
>
> 2010/11/19 Mathew Johnston <mjohnston at capsaicin.ca>:
> > Hi,
> > I'm trying to develop my first high performance HTTPS based application
> > using Netty, starting with the SecureChat and HTTP server examples. I
> > noticed that the examples use a dummy implementation of TrustManager and
> > load a KeyStore from a short[]. I assume that this is simply to make it
> > convenient to get a working example to run. E.g. remove the need for
> someone
> > to create a trust/key store before running the example.
> > I'd like my app to use the default TrustStore/KeyStore loading from file
> > (using system properties for config), as well as the standard certificate
> > trust checks but am having trouble making the necessary modification. I
> kind
> > of assumed that I could just pass SSLContext.init() some nulls and it
> would
> > make sensible default choices, but I'm getting a "no cipher suites in
> > common" exception.
> > Here's a snippit of the code I'm using (a modification of
> > HttpServerPipelineFactory from the examples):
> >
> > // Create a default pipeline implementation.
> > ChannelPipeline pipeline = pipeline();
> > // Create TrustManagerFactory for PKIX-compliant trust managers
> > TrustManagerFactory factory =
> > TrustManagerFactory.getInstance("PKIX");
> > KeyStore ks = null;
> > factory.init(ks);
> > SSLContext sslContext = SSLContext.getInstance("TLS");
> >
> > sslContext.init(null, factory.getTrustManagers(), null);
> > TrustManager[] managers = factory.getTrustManagers();
> > for (TrustManager m : managers) {
> > X509TrustManager mgr = (X509TrustManager)m;
> > for (X509Certificate c : mgr.getAcceptedIssuers()) {
> > System.out.println("DEBUG: Trusted Certificate: " +
> > c.getSubjectDN());
> > }
> > }
> >
> > SSLEngine engine = sslContext.createSSLEngine();
> > for (String suite : engine.getEnabledCipherSuites()) {
> > System.out.println("DEBUG: Enabled cipher: " + suite);
> > }
> > engine.setUseClientMode(false);
> >
> > pipeline.addLast("ssl", new SslHandler(engine));
> >
> > When running this, I do see my loaded CA certificate (TrustStore)
> printed.
> > I'm not sure how to easily enumerate the private keys that are loaded,
> but I
> > assume they're loaded as well. The ciphers enabled include:
> > SSL_RSA_WITH_RC4_128_MD5
> > SSL_RSA_WITH_RC4_128_SHA
> > TLS_RSA_WITH_AES_128_CBC_SHA
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> > SSL_RSA_WITH_3DES_EDE_CBC_SHA
> > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> > SSL_RSA_WITH_DES_CBC_SHA
> > SSL_DHE_RSA_WITH_DES_CBC_SHA
> > SSL_DHE_DSS_WITH_DES_CBC_SHA
> > SSL_RSA_EXPORT_WITH_RC4_40_MD5
> > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
> > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> > TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> > When I try to connect, I get the following exception:
> > javax.net.ssl.SSLHandshakeException: no cipher suites in common
> > at com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Unknown
> > Source)
> > at
> > com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(Unknown
> Source)
> > at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown
> > Source)
> > at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown
> Source)
> > at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
> > at
> > org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:868)
> > at
> > org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:605)
> > at
> >
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
> > at
> >
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)
> > at
> > org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
> > at
> > org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
> > at
> > org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:350)
> > at
> >
> org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
> > at
> > org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
> > at
> >
> org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> > Source)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> > Source)
> > at java.lang.Thread.run(Unknown Source)
> > Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in
> common
> > at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
> > Source)
> > at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown
> Source)
> > at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown
> Source)
> > at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown
> Source)
> > at
> > com.sun.net.ssl.internal.ssl.ServerHandshaker.chooseCipherSuite(Unknown
> > Source)
> > at
> com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(Unknown
> > Source)
> > at
> > com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown
> Source)
> > at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown
> > Source)
> > at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at
> com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown
> > Source)
> > at
> org.jboss.netty.handler.ssl.SslHandler$2.run(SslHandler.java:999)
> > at
> >
> org.jboss.netty.handler.ssl.ImmediateExecutor.execute(ImmediateExecutor.java:37)
> > at
> >
> org.jboss.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:996)
> > at
> > org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:886)
> > ... 12 more
> > I saw http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6448723 and
> wonder
> > if my issue may be related. Would SSLContext.init() be initializing with
> an
> > X509KeyManager instead of an X509ExtendedKeyManager as the bug report
> > suggests I would require? If so, is there a convenient way of getting
> around
> > this issue while maintaining the default keystore loading behavior?
> > Ultimately, I do want to validate the client certificate when it
> connects,
> > if that changes anything.
> > I very much appreciate the attention you've given if you've made it this
> far
> > :) Thanks!
> > Mathew Johnston
> > _______________________________________________
> > netty-users mailing list
> > netty-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/netty-users
> >
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20110110/7c5e89d1/attachment-0001.html
More information about the netty-users
mailing list