Re: HttpConduitTest failed when Jetty upgraded to 6.1.3

[Polar Humenn]

I remember that discussion about the keystore and truststore defaults, 
but in anycase, that really doesn't matter so much if you can specify it 
in config.

However, the problem is when the Keystore  containing the authentication 
key and certificate is PKCS12 forces the TrustStore to be a single 
PEM/DER encoded certificate, regardless of what the TrustStoreType 
element says.



Glynn, Eoghan wrote:
 

  
-----Original Message-----
From: Polar Humenn [mailto:[EMAIL PROTECTED] 
Sent: 16 May 2007 14:05
To: cxf-dev@incubator.apache.org
Subject: Re: HttpConduitTest failed when Jetty upgraded to 6.1.3

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>
    


We already have a SSL{Client|Server}Policy.TrustStoreType defined in the
security.xsd.

But the confusion may have been caused by the default keystore type
being PKCS12, whereas the default truststore type is JKS (see
SSLUtils.java).

Fred brought this up on the list a while back[1]. In fact now that I've
dug up Fred's mail, I notice he also mentioned the lack of a
TrustStorePassword element.

I can't remember all the details of that previous discussion, but I
think the consensus was to change to a single default store type of JKS.
Obviously hasn't become a reality on the trunk yet though.

Cheers,
Eoghan.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200704.mbox/%
[EMAIL PROTECTED]


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