cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: HttpConduitTest failed when Jetty upgraded to 6.1.3
Date Wed, 16 May 2007 13:04:44 GMT
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.

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.

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>

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


Mime
View raw message