You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by saurabh jain <sa...@gmail.com> on 2016/05/16 14:24:26 UTC
IbmX509 KeyManager and TrustManager algorithm not supported
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
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by Chris Nauroth <cn...@hortonworks.com>.
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" <sa...@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 <sa...@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
>><sa...@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 <
>> sauravmanit@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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by saurabh jain <sa...@gmail.com>.
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 <sa...@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 <sa...@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 <
> sauravmanit@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by Patrick Hunt <ph...@apache.org>.
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 <sa...@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 <sa...@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 <sauravmanit@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
> > > > >
> > > >
> > >
> >
>
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by saurabh jain <sa...@gmail.com>.
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 <sa...@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 <sa...@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
> > > >
> > >
> >
>
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by Patrick Hunt <ph...@apache.org>.
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 <sa...@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 <sa...@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
> > >
> >
>
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by saurabh jain <sa...@gmail.com>.
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 <sa...@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
> >
>
Re: IbmX509 KeyManager and TrustManager algorithm not supported
Posted by Patrick Hunt <ph...@apache.org>.
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 <sa...@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
>