Looking at the code, I'm not really seeing an "easy" way to do it.
The only way I can see it working is to write your own
TrustManagerFactory that would return your TrustManager. The
tlsClientParameters stuff can specify a provider that would be
used. Unforunately, you'll still need a keystore for that to work,
although you probably could use any keystore.
Dan
On Jul 30, 2008, at 1:24 PM, John Hite wrote:
I don't think I want a TrustDecider. The TrustDecider is invoked
after the
TLS handshake right? I'm afraid that the TLS handshake will fail
because the
client does not know if it should trust the server. I have a
TrustManager
implementation (it extends javax.net.ssl.X509TrustManager) that I am
using
to verify trust based on the server certificate. I can use this
programmatically by doing:
TLSClientParameters tls = new TLSClientParameters();
tls.setTrustManagers(new TrustManager[]{new CustomTrustManager()});
httpConduit.setTlsClientParameters(tls);
This works just fine, but I can't find a way to do this in
configuration.
Thanks for your help,
John
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of
Glen Mazza
Sent: Wednesday, July 30, 2008 1:00 PM
To: [email protected]
Subject: RE: Custom TLS TrustManager
Do you mean a Trust*Decider*, not a TrustManager? CXF has both
critters.
Glen
John Hite wrote:
Hi Glen,
Thanks for the reply. I guess I didn't make my problem clear
enough. The
only option for the sec:trustManager is to provide a java keystore.
I want
to provide a java class.
Thanks,
John
--
View this message in context:
http://www.nabble.com/Custom-TLS-TrustManager-tp18725323p18737902.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
