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.
