Yes, I'm aware of that limitation in CXF. I figured it would be
relatively straightforward to fix in CXF (assuming people are willing
in this forum), but harder in Jetty. I can make the recommendation
to the Jetty folks, as well, since it seems like it is a reasonable
request.
(There have been cases, for example, where I've had to use in-memory
Keystores just as canonical structures for key data -- the key data
itself may be obtained in an application-specific manner -- e.g.,
through a PKI)
Yes -- dumping to a file is the only viable approach, though this
also means (in my particular case) that the CXF config file also
needs to be run through sed or equiv to lay down the right path. A
bit of a hack, but it should work for my purposes.
Thanks!
-Fred"Who turned off MIME attachments -- sorry 'bout that"Dushin
On Feb 23, 2007, at 5:50 AM, Glynn, Eoghan wrote:
Fred,
Note that even in the client-side HttpsURLConnection-based code, AFAIK
the CXF code also wouldn't support using a pre-existing in-memory
representation of the keystore ... i.e. it expects to load the
keystore
from a file. See SSLUtils.getKeyStoreManagers().
If you need the capability to pull in keystores from memory just for
testing, then I'd suggest it would be easier to just take a pragmatic
approach and dump into a temp file, rather than contributing a
change to
Jetty. The reason I say this is that right now we depend on two
separate
versions of Jetty, one current but the other quite old at this stage,
which would complicate the process of getting your change into
released
snapshots on which we could depend.
/Eoghan
-----Original Message-----
From: Fred Dushin [mailto:[EMAIL PROTECTED]
Sent: 22 February 2007 21:42
To: [email protected]
Subject: In-memory Keystores, and Jetty
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been looking into Jetty, and in particular, its
initialization of TLS endpoint information via Java Keystores.
One thing I've found in the CXF use of Jetty is CXF populates
an org.mortbay.http.SslListener in
org.apache.cxf.transport.https.JettySslListenerFactory#decorate():
public void decorate(SslListener secureListener) {
String keyStoreLocation =
SSLUtils.getKeystore(sslPolicy.getKeystore(), LOG);
secureListener.setKeystore(keyStoreLocation);
...
The idea being that later, the SslListener will load the
keystore off the URL:
protected SSLServerSocketFactory createFactory()
throws Exception
{
...
KeyStore keyStore = KeyStore.getInstance(_keystoreType);
keyStore.load(Resource.newResource(_keystore).getInputStream
(), _password.toString().toCharArray());
...
}
However, this API on the Jetty SslListener type requires that
the Keystore be referenced indirectly through a string (it
seems that URLs are supported, though I don't see why you'd
want to get your keystore from an ftp server). Not sure just
what the security implications are there...
In any event there doesn't seem to be a way of initializing
the connection with a Keystore that already in memory, which
is too bad, because an application may already have one in
memory, which it may have acquired by its own nefarious
methods. As it is, the application will need to serialize
the thing to disk somehow.
It also makes testing a pain, in my particular case :)
Anyway, I don't see a way around this, other than by a fix to
Jetty.
Has this come up before?
Thanks,
Fred
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iD8DBQFF3g4CKSQw0yA4Kl8RAlogAJ4we6ZEXvFmZEVQ9hlk+NhvKUV+0QCdESi+
4HCKSLWTcBwwfDHnyDwHOvg=
=RcrX
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iD8DBQFF3g5FKSQw0yA4Kl8RAtYvAJ49Z1+TuqGo5p6sFUwG3m93bZ1wOACgiNlj
FmQf5MBcbJI/gl/CSouubKI=
=4M8k
-----END PGP SIGNATURE-----
