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

Marc-André Laverdière marcandre.laverdiere at gmail.com
Mon Nov 29 04:47:29 EST 2010 

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
>

More information about the netty-users mailing list