How to use default SSL TrustStore/KeyStore loading and trust behavior - getting no cipher suites in common

[Mathew Johnston]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20101119/891c372c/attachment-0001.html