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