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----- >
