Any chance there was a change of JRE version in there? Java 1.3 is more strict than Java 1.4 in this case. I know nothing of Axis but HttpClient uses the default JSSE socket factory and sockets so it inherits whatever restrictions the version of JSSE you have implements. You can however use your own socket factory. There's a hot off the press SSL guide that's just been written and is being reviewed for HttpClient, it's available in XML form at http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=6644
HttpClient includes a example SocketFactory and TrustManager to avoid problems with untrusted certs - so no, it doesn't nessecarily work out of the box. In your case it sounds like Axis has a corrupt keystore or similar problem but is using a different keystore to the standard JSSE one. That's pretty much just a wild guess though. Regards, Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -----Original Message----- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Friday, 6 June 2003 3:57 AM To: [EMAIL PROTECTED] Subject: [httpclient] Q about how HttpClient handles "trust stores" in SSL, vs. how Axis does it I don't know a lot about this, but I had a colleague who was having some trouble getting an SSL connection working from Axis. I thought this was curious, because when I plugged in HttpClient for an SSL connection, it worked on the first try. He, however, is getting some error about "unable to validate trust store" or something like that. He's apparently finding that he needs to deploy a different SocketFactory, or something, that handles trust stores in a different way. Does anyone know this works out of the box in HttpClient, but requires more work in Axis? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
