[ https://issues.apache.org/jira/browse/ZOOKEEPER-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299391#comment-15299391 ]
Saurabh Jain commented on ZOOKEEPER-2429: ----------------------------------------- Started working on this. Making the KeyManager and TrustManager algorithm as a configurable property , which user can pass as the vm arguments. In addition to the already existing properties -Dzookeeper.ssl.keyStore.location -Dzookeeper.ssl.keyStore.password -Dzookeeper.ssl.trustStore.location -Dzookeeper.ssl.trustStore.password 2 new properties can also be defined in the server startup script. -Dzookeeper.ssl.keyManager.algorithm -Dzookeeper.ssl.trustManager.algorithm If the properties are missing then it will fallback to the default algorithm supported by underlying jre. > IbmX509 KeyManager and TrustManager algorithm not supported > ----------------------------------------------------------- > > Key: ZOOKEEPER-2429 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2429 > Project: ZooKeeper > Issue Type: Bug > Components: security, server > Affects Versions: 3.5.0 > Reporter: Saurabh Jain > Assignee: Saurabh jain > Priority: Minor > Fix For: 3.5.1 > > > 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()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)