cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: In-memory Keystores, and Jetty
Date Fri, 23 Feb 2007 15:22:23 GMT

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  

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

-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 []
>> Sent: 22 February 2007 21:42
>> To:
>> Subject: In-memory Keystores, and Jetty
>> Hash: SHA1
>> 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-----
>> Version: GnuPG v1.4.6 (Darwin)
>> iD8DBQFF3g5FKSQw0yA4Kl8RAtYvAJ49Z1+TuqGo5p6sFUwG3m93bZ1wOACgiNlj
>> FmQf5MBcbJI/gl/CSouubKI=
>> =4M8k
>> -----END PGP SIGNATURE-----

View raw message