Additional user-facing configuration for this might not be necessary, and it might push more operational complexity onto administrators. FWIW, there is a bit of code in Hadoop that takes the approach of runtime detection of the IBM JRE, and then automatically toggles between the two algorithms. See the SSLFactory [1] and PlatformName [2] classes.
A challenge we've had in the Hadoop community is that not many (none?) of the committers have access to the IBM JRE for verification of proposed patches. Saurabh, if you can help on any testing efforts related to IBM JRE support, we would greatly appreciate that. I'll echo these comments on ZOOKEEPER-2429. [1] https://s.apache.org/aYyi [2] https://s.apache.org/euiW --Chris Nauroth On 5/17/16, 10:04 AM, "saurabh jain" <sauravma...@gmail.com> wrote: >Yeah , I created my jira user account recently more specifically on 13th >may I think. > >Nevermind we can track with this new jira (2429). > >Please assign this jira to me. > >On Tue, May 17, 2016 at 12:06 PM, Patrick Hunt <ph...@apache.org> wrote: > >> The Apache infra team has been dealing with a massive JIRA spam attack >>over >> the past few days (not the first time). I'm not sure but it could be >>that >> some of the counter-measures and/or cleanup implemented by the infra >>team >> to address the spam may have caused your jira to go missing. Did you >>create >> your JIRA user account recently? Regardless, I recommend you recreate >>your >> jira - sorry for the trouble! >> >> Patrick >> >> >> On Tue, May 17, 2016 at 8:22 AM, saurabh jain <sauravma...@gmail.com> >> wrote: >> >> > I had created a new jira for this - >> > https://issues.apache.org/jira/browse/ZOOKEEPER-2429. >> > I will go through the process on how to contribute and will submit the >> > patch as per Patrick's recommendation. >> > >> > >> > >> > On Tue, May 17, 2016 at 10:14 AM, Patrick Hunt <ph...@apache.org> >>wrote: >> > >> > > There was a discussion about that recently, looks like an INFRA >>issue, >> > see >> > > http://markmail.org/message/r2nbgezn7cpldupz >> > > >> > > Try re-creating the jira. >> > > >> > > Patrick >> > > >> > > >> > > On Tue, May 17, 2016 at 7:02 AM, saurabh jain >><sauravma...@gmail.com> >> > > wrote: >> > > >> > > > Hello Patrick, >> > > > >> > > > Yeah , that would be flexible to make it configurable. >> > > > Can I open a Jira for this ? >> > > > >> > > > Earlier I created a jira (ZOOKEEPER-2428) for this not sure why it >> was >> > > > removed. >> > > > >> > > > Thanks, >> > > > Saurabh >> > > > >> > > > On Mon, May 16, 2016 at 6:20 PM, Patrick Hunt <ph...@apache.org> >> > wrote: >> > > > >> > > > > Makes sense to me. However I'd recommend that you make it >> > configurable. >> > > > > Make the default getDefaultAlgo, but allow it to be overridden >>by >> the >> > > > user >> > > > > via configuration at the ZK level. Print a debug level message >>with >> > the >> > > > > value used for debuggability. >> > > > > >> > > > > Patrick >> > > > > >> > > > > On Mon, May 16, 2016 at 7:24 AM, saurabh jain < >> sauravma...@gmail.com >> > > >> > > > > wrote: >> > > > > >> > > > > > Hello All , >> > > > > > >> > > > > > When connecting from a zookeeper client running in IBM >>WebSphere >> > > > > > Application Server version 8.5.5, with SSL configured in >> ZooKeeper, >> > > the >> > > > > > below mentioned exception is observed. >> > > > > > >> > > > > > org.jboss.netty.channel.ChannelPipelineException: Failed to >> > > initialize >> > > > a >> > > > > > pipeline. >> > > > > > at org.jboss.netty.bootstrap.ClientBootstrap.connect( >> > > > > > ClientBootstrap.java:208) >> > > > > > at org.jboss.netty.bootstrap.ClientBootstrap.connect( >> > > > > > ClientBootstrap.java:182) >> > > > > > at org.apache.zookeeper.ClientCnxnSocketNetty.connect( >> > > > > > ClientCnxnSocketNetty.java:112) >> > > > > > at org.apache.zookeeper.ClientCnxn$SendThread. >> > > > > > startConnect(ClientCnxn.java:1130) >> > > > > > at org.apache.zookeeper.ClientCnxn$SendThread.run( >> > > > > > ClientCnxn.java:1158) >> > > > > > Caused by: >> > > > org.apache.zookeeper.common.X509Exception$SSLContextException: >> > > > > > Failed to create KeyManager >> > > > > > at >>org.apache.zookeeper.common.X509Util.createSSLContext( >> > > > > > X509Util.java:75) >> > > > > > at >> > > > > > >> org.apache.zookeeper.ClientCnxnSocketNetty$ZKClientPipelineFactory. >> > > > > > initSSL(ClientCnxnSocketNetty.java:358) >> > > > > > at >> > > > > > >> org.apache.zookeeper.ClientCnxnSocketNetty$ZKClientPipelineFactory. >> > > > > > getPipeline(ClientCnxnSocketNetty.java:348) >> > > > > > at org.jboss.netty.bootstrap.ClientBootstrap.connect( >> > > > > > ClientBootstrap.java:206) >> > > > > > ... 4 more >> > > > > > Caused by: >> > > > org.apache.zookeeper.common.X509Exception$KeyManagerException: >> > > > > > java.security.NoSuchAlgorithmException: SunX509 >>KeyManagerFactory >> > not >> > > > > > available >> > > > > > at >>org.apache.zookeeper.common.X509Util.createKeyManager( >> > > > > > X509Util.java:129) >> > > > > > at >>org.apache.zookeeper.common.X509Util.createSSLContext( >> > > > > > X509Util.java:73) >> > > > > > ... 7 more >> > > > > > Caused by: java.security.NoSuchAlgorithmException: SunX509 >> > > > > > KeyManagerFactory not available >> > > > > > at >> > > sun.security.jca.GetInstance.getInstance(GetInstance.java:172) >> > > > > > at javax.net.ssl.KeyManagerFactory.getInstance( >> > > > > > KeyManagerFactory.java:9) >> > > > > > at >>org.apache.zookeeper.common.X509Util.createKeyManager( >> > > > > > X509Util.java:118) >> > > > > > >> > > > > > >> > > > > > Reason : IBM websphere uses its own jre and supports only >>IbmX509 >> > > > > > keymanager algorithm which is causing an exception when >>trying to >> > get >> > > > an >> > > > > > key manager instance using SunX509 which is not supported. >> > > > > > Currently KeyManager algorithm name (SunX509) is hardcoded in >> the >> > > > class >> > > > > > X509Util.java. >> > > > > > >> > > > > > Possible fix: Instead of having algorithm name hardcoded to >> SunX509 >> > > we >> > > > > can >> > > > > > fall back to the default algorithm supported by the underlying >> jre. >> > > > > > >> > > > > > Instead of having this - >> > > > > > KeyManagerFactory kmf = >>KeyManagerFactory.getInstance("SunX509"); >> > > > > > TrustManagerFactory tmf = >> > TrustManagerFactory.getInstance("SunX509"); >> > > > > > >> > > > > > can we have ? >> > > > > > KeyManagerFactory kmf = >> > > > KeyManagerFactory.getInstance(KeyManagerFactory. >> > > > > > getDefaultAlgorithm()); >> > > > > > >> > > > > > TrustManagerFactory tmf = TrustManagerFactory.getInstance( >> > > > > > TrustManagerFactory.getDefaultAlgorithm()); >> > > > > > >> > > > > > Please advise. >> > > > > > >> > > > > > Thanks, >> > > > > > Saurabh >> > > > > > >> > > > > >> > > > >> > > >> > >>
