Thanks for the help. I'll keep it in mind. I did end up importing the server's cert, and also setting the targetObjectURI. If I leave this targetObjectURI out, interestingly enough, it gives the "bad request error".
My most recent (and pernicious) problem is that I keep getting a "None of the matching operations for soapAction XXXXX could successfully load the incoming request. Potential typemapper problem. I posted this in another message to this list. I even tried Axis to see if I might have the same problem, but I'm having problems even connecting via SSL in Axis... -----Original Message----- From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 4:55 PM To: [EMAIL PROTECTED] Subject: Re: Debugging SOAP called over SSL One person that I dealt with had the same problem ( can't post to our web server via HTTPS ), and he claims to have imported our certificate ( self-signed ) and our CA certificate into Java's cacerts file. It turned out they did, but they have multipled Java installations ... and the Java that was running when posting to us was not the Java installation where they imported our certificates. Jesus M. Salvo Jr. wrote: > Robert Dietrick wrote: > >> With TcpTunnel you'll be able to see whether or not there is >> communication between the client & server, but you won't be able to >> decipher the contents of it unless you have an innate ability to do >> decryption, in which case you should get yourself a job at the NSA. >> > Now come on ..... You have two options: > > 1) If you manager the webserver server that is running SSL, you need > the private key for the server's certificate. With that in hand, you > can decrpyt the SSL traffic using ssldump. > > 2) If option [1] is not available, you won't be able to descrypt the > SSL traffic ... but ... you can still get some idea of what's > happening during the SSL handshake. Use a network sniffer that > understands SSL ( e.g.: ssldump or ethereal ), and watch the SSL > handshake closely. Those "bad request to server" responses that you > are getting is an indication something went wrong in the SSL handshake > ... and in my experience, the certificate(s) was not validated (e.g.: > If the certificates are self-signed, check to see that the certificate > plus the CA's certificate are sent in the handshake .. the sending of > certificates are not encrypted ), or there was a disagreement on the > algorithm to use, etc ... > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0BA5348 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
