cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <ning.ji...@iona.com>
Subject Re: HttpConduitTest failed when Jetty upgraded to 6.1.3
Date Thu, 17 May 2007 02:21:09 GMT
Hi Polar,

Please see my comments in the mail.

Polar Humenn wrote:
> Aside from the incompatibilities with a new version of Jetty, CXF SSL 
> configuration has a lot of shortcomings. I've been burned by the same 
> thing.
>
> First of all, as Eoghan might say, I tore my hair out, before I found 
> out that if your authentication certificate/key is in a PKCS12 format, 
> then your TrustStore has to be a PEM certificate, not a truststore, 
> i.e. PCKS12 or Java Key Store (JKS) format. This must have made sense 
> to someone about not mixing PCKS12 with JKS or others, but makes no 
> logical sense to me. So, Willem, if the truststore is *just* a 
> certificate, then there is no password possible. Furthermore, when you 
> use this approach you are only allowed to have *1* certificate in the 
> truststore.
>
I don't mean not to set the TrustStroePassword to be null.
Current Jetty SslSocketConnector don't support to set the 
TrustStroePassword to be null.
Now I don't find a way to walk around it. It just may take some time to 
convince Jetty guys to change the code.
> So, the basic upshot is that if you initialize a PCKS12 
> key/certificate, then you are only allowed to have only 1 trust 
> point.  Most browsers have something like 100.
>
We can support the TrustStroePassword with null value in CXF , right.
> So, this approach is really unacceptable. I would like to revamp SSL 
> configuration and the whole approach to include:
>
> 1. Different types Keystores for the the authentication private 
> keys/certificates/chains.
> 2. Different types of password protected TrustStores with multiple 
> trust points.
>     2a. I don't really care about passwords on TrustStores, as they 
> are mainly for
>           for integrity protection (somebody doesn't slip on in 
> there), but the user
>           should have the option of forgoing that, say, just a 
> concatenated list of
>           of PEM certificates.
> 3. Remove the restrictions between the keystore type and the 
> truststore type.
>
> Thinking quickly, this will add two elements to the SSL Policy 
> configuration for both Client and Server sides.
>
> <TrustStoreType>
> <TrustStorePassword>
>
Let's add the TrueStorePassword to the SSL Policy configuration. :)
> Cheers,
> -Polar
>
> Willem Jiang wrote:
>> Hi
>>
>> I found the HttpConduitTest failed in Systest when I upgraded the 
>> Jetty version from 6.1.2rc0 to 6.1.3.
>> I checked the Jetty's SslSocketConnector change log, and found that 
>> the errors are related with the different trustManager
>> setting on the Server and Client side. In another words,CXF now does 
>> not support to load the cert with password.
>>
>> Current CXF JettySslConnectorFactory doesn't do any trustManager 
>> setting, and the jetty will set the trustManagers to null,
>> if there is no setting for the _truststore.
>> But after Jetty 6.1.2rc5, the TrustManager will be initiated whether 
>> you do the trustManager setting or not.
>>
>> [*Server side*]
>>
>> Here is the Jetty SslSocketConnector TrustManagers Code, the 
>> trustStore load the  with a _trustPassword which can't be null.
>>
>> >>> after 6.1.2rc5
>>        if (_truststore==null)
>>        {
>>            _truststore=_keystore;
>>            _truststoreType=_keystoreType;
>>        }
>> >>>>
>>       ......
>>       TrustManager[] trustManagers = null;
>>       if (_truststore != null)
>>        {
>>            KeyStore trustStore = KeyStore.getInstance(_truststoreType);
>>            
>> trustStore.load(Resource.newResource(_truststore).getInputStream(), 
>> _trustPassword.toString().toCharArray());
>>                      TrustManagerFactory trustManagerFactory = 
>> TrustManagerFactory.getInstance(_sslTrustManagerFactoryAlgorithm);
>>            trustManagerFactory.init(trustStore);
>>            trustManagers = trustManagerFactory.getTrustManagers();
>>        }
>>
>> [*Client side*]
>> CXF SSLUtil is responsible for the creation of  the TrustManager,  
>> but it just load the cert with null password.
>> protected static TrustManager[] getTrustStoreManagers( ...
>>           KeyStore trustedCertStore = 
>> KeyStore.getInstance(trustStoreType);
>>  ......               trustedCertStore.load(new 
>> FileInputStream(trustStoreLocation), null);
>>  ......
>> I went through The SSLClientPolicy and SSLServerPolicy , there is no 
>> attribute for the TrustStorePassword.
>>
>> I also check the KeyStore.loadload(InputStream stream, char[] 
>> password) API
>> *the password used to check the integrity of  the keystore, the 
>> password used to unlock the keystore,  or <code>null</code> *
>>
>> This issue can be solved from two side.
>> One is let Jetty SslSocketConnector support calling the 
>> trustStore.load with the password to be null.
>> The other is we still need CXF SSL{Client|Server}Policy support 
>> TrustStorePassword attribute.
>>
>> IMO, we need to add the TrustStorePassword attribute to the 
>> SSL{Client|Server}Policy.
>>
>> Any thoughts?
>>
>> Cheers,
>> Willem.
>>
>
>
>
Cheers,
Willem.


Mime
View raw message