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:20:20 GMT
Hi Eoghan,

Glynn, Eoghan wrote:
> Hi Willem,
>
> Sounds like an over-sight that the SSL{Client|Server}Policy schemas
> include a KeystorePassword but not a TruststorePassword. So unless
> anyone else knows a specific reason why this wasn't included in the
> first place, I'd say go ahead and add it.
>
>   
I'd like to do it.
> I think the use of a null TrustManager[] in JettySslConnectorFactory
> derives from a short-coming in the old Jetty5 SslListener, whuch didn't
> include anything like the Jetty6 SslSocketConnector.setTrust*() APIs.
>
> Now that the Jetty6 allows the truststore parameters to be set, these
> new APIs should be used.
>
>   
Yes, now we can support to set the truststore parameters on the CXF 
server side.

BTW
What the consequence will be, if the the TrustManager[] set to be null ?
Will the server not take care of the  client  certification?

Thanks,

Willem.
> /Eoghan
>
>   
>> -----Original Message-----
>> From: Willem Jiang [mailto:ning.jiang@iona.com] 
>> Sent: 16 May 2007 05:14
>> To: cxf-dev@incubator.apache.org
>> Subject: HttpConduitTest failed when Jetty upgraded to 6.1.3
>>
>> 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.
>>
>>
>>     
>
>
>   



Mime
View raw message