You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/07/31 14:16:49 UTC
critical jetty keystore problems on 1.1.1
I'm still trying to figure out some critical problems with the keystore
processing on jetty.
The most serious problem that I've yet to resolve is a problem with the
lock/unlock of the keystore availability lock. A subsequent server
restart will fail because "Keystore 'geronimo-default' is locked". It
appears that we cannot recover from this error either. Even if I change
the config.xml for SSLConnector to load="false", restart the server,
unlock the keystore/key (again) I still get the same failure when I
attempt to start with the SSLConnector enabled.
At first I thought this was because of the duplicate attribute entries
referenced in an earlier post. In fact, I'm pretty sure that I edited
the config.xml to remove the "null" entries and was able to get the
server started. However, I have recently been unable to recover from
this error using the same mechanism. In fact it seems to create more
problems because after removing the null entries I now get an
UnrecoverableKeyException.
Any advice or recommendations? I'm beginning to wonder if we should
disable the keystore portlet for 1.1.1 so that the user can't shoot
himself in the foot.
Joe
Re: critical jetty keystore problems on 1.1.1
Posted by Joe Bohn <jo...@earthlink.net>.
I think that Aaron raised this issue (or indicated there might be a
problem here) in a previous post on an earlier thread.
Aaron suggested that there be a wiki page or some other summary page
that explains what we think we need to have functionally so that it can
be agreed upon and them implemented in a future Geronimo release. Can
you take a stab at this summary Vamsi? I think that you along with
David Jencks, Aaron, and possibly a few others will need to reach a
consensus.
Joe
Vamsavardhana Reddy wrote:
> Looks like there is no point in having more than one private key entry
> in a keystore for the purpose of SSL Server authentication as there is
> no control on which key will be picked. I do not know if this is useful
> for Client authentication. Unless all the private key entries have the
> same password, KeyManagerFactory.init() will throw an exception.
>
> -Vamsi
>
> On 7/31/06, *Joe Bohn* <joe.bohn@earthlink.net
> <ma...@earthlink.net>> wrote:
>
> Just an update on this problem.
>
> There is still a problem with the locking (esp. in jetty) due to
> multiple attributes (containing both the password value and null) for
> the keystorePassword and keyPasswords. However, with the fix just
> integrated for GERONIMO-2252 we at least have some recovery plan (modify
> the config.xml to remove the null entries and the remain stored entries
> will correctly unlock the keys).
>
> Thanks to Vamsavardhana Reddy for finding the root cause of why the
> passwords were being stored incorrectly. Now we just need to figure out
> why we're ending up with multiple entries in config.xml for the same
> attributes.
>
> Joe
>
> Joe Bohn wrote:
> >
> > I'm still trying to figure out some critical problems with the
> keystore
> > processing on jetty.
> >
> > The most serious problem that I've yet to resolve is a problem
> with the
> > lock/unlock of the keystore availability lock. A subsequent server
> > restart will fail because "Keystore 'geronimo-default' is
> locked". It
> > appears that we cannot recover from this error either. Even if I
> change
> > the config.xml for SSLConnector to load="false", restart the server,
> > unlock the keystore/key (again) I still get the same failure when I
> > attempt to start with the SSLConnector enabled.
> >
> > At first I thought this was because of the duplicate attribute
> entries
> > referenced in an earlier post. In fact, I'm pretty sure that I
> edited
> > the config.xml to remove the "null" entries and was able to get the
> > server started. However, I have recently been unable to recover from
> > this error using the same mechanism. In fact it seems to create
> more
> > problems because after removing the null entries I now get an
> > UnrecoverableKeyException.
> >
> > Any advice or recommendations? I'm beginning to wonder if we should
> > disable the keystore portlet for 1.1.1 so that the user can't shoot
> > himself in the foot.
> >
> > Joe
> >
> >
>
>
Re: critical jetty keystore problems on 1.1.1
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Looks like there is no point in having more than one private key entry in a
keystore for the purpose of SSL Server authentication as there is no control
on which key will be picked. I do not know if this is useful for Client
authentication. Unless all the private key entries have the same password,
KeyManagerFactory.init() will throw an exception.
-Vamsi
On 7/31/06, Joe Bohn <jo...@earthlink.net> wrote:
>
> Just an update on this problem.
>
> There is still a problem with the locking (esp. in jetty) due to
> multiple attributes (containing both the password value and null) for
> the keystorePassword and keyPasswords. However, with the fix just
> integrated for GERONIMO-2252 we at least have some recovery plan (modify
> the config.xml to remove the null entries and the remain stored entries
> will correctly unlock the keys).
>
> Thanks to Vamsavardhana Reddy for finding the root cause of why the
> passwords were being stored incorrectly. Now we just need to figure out
> why we're ending up with multiple entries in config.xml for the same
> attributes.
>
> Joe
>
> Joe Bohn wrote:
> >
> > I'm still trying to figure out some critical problems with the keystore
> > processing on jetty.
> >
> > The most serious problem that I've yet to resolve is a problem with the
> > lock/unlock of the keystore availability lock. A subsequent server
> > restart will fail because "Keystore 'geronimo-default' is locked". It
> > appears that we cannot recover from this error either. Even if I change
> > the config.xml for SSLConnector to load="false", restart the server,
> > unlock the keystore/key (again) I still get the same failure when I
> > attempt to start with the SSLConnector enabled.
> >
> > At first I thought this was because of the duplicate attribute entries
> > referenced in an earlier post. In fact, I'm pretty sure that I edited
> > the config.xml to remove the "null" entries and was able to get the
> > server started. However, I have recently been unable to recover from
> > this error using the same mechanism. In fact it seems to create more
> > problems because after removing the null entries I now get an
> > UnrecoverableKeyException.
> >
> > Any advice or recommendations? I'm beginning to wonder if we should
> > disable the keystore portlet for 1.1.1 so that the user can't shoot
> > himself in the foot.
> >
> > Joe
> >
> >
>
Re: critical jetty keystore problems on 1.1.1
Posted by Joe Bohn <jo...@earthlink.net>.
Just an update on this problem.
There is still a problem with the locking (esp. in jetty) due to
multiple attributes (containing both the password value and null) for
the keystorePassword and keyPasswords. However, with the fix just
integrated for GERONIMO-2252 we at least have some recovery plan (modify
the config.xml to remove the null entries and the remain stored entries
will correctly unlock the keys).
Thanks to Vamsavardhana Reddy for finding the root cause of why the
passwords were being stored incorrectly. Now we just need to figure out
why we're ending up with multiple entries in config.xml for the same
attributes.
Joe
Joe Bohn wrote:
>
> I'm still trying to figure out some critical problems with the keystore
> processing on jetty.
>
> The most serious problem that I've yet to resolve is a problem with the
> lock/unlock of the keystore availability lock. A subsequent server
> restart will fail because "Keystore 'geronimo-default' is locked". It
> appears that we cannot recover from this error either. Even if I change
> the config.xml for SSLConnector to load="false", restart the server,
> unlock the keystore/key (again) I still get the same failure when I
> attempt to start with the SSLConnector enabled.
>
> At first I thought this was because of the duplicate attribute entries
> referenced in an earlier post. In fact, I'm pretty sure that I edited
> the config.xml to remove the "null" entries and was able to get the
> server started. However, I have recently been unable to recover from
> this error using the same mechanism. In fact it seems to create more
> problems because after removing the null entries I now get an
> UnrecoverableKeyException.
>
> Any advice or recommendations? I'm beginning to wonder if we should
> disable the keystore portlet for 1.1.1 so that the user can't shoot
> himself in the foot.
>
> Joe
>
>