Lukas, As my professor used to say: "there are ways of seeing and not seeing". So, interpretations of a spec may differ, and different SSL implementations may differ in the degree of spec compliance and may have implementation specific quirks.
Just recently I had to deal with a compatibility issue between Sun JSSE and a Deplhi written SSL library called SecureBlackBox. It was quite a pain in the <self-censored>. This kind of problem can never be completely ruled out If you are already familiar with HttpClient have a look at this patch http://issues.apache.org/bugzilla/show_bug.cgi?id=29306 It implements a version of SSL socket factory that controls pretty much all the aspects of SSL authentication. It also logs quite extensively, so you may see what is actually going on during SSL context negotiation. Feel free to use it as a starting point. For a start you may choose to trust any certificate and see if that makes any difference. Oleg On Wed, 2004-06-09 at 21:25, Lukas Bradley wrote: > The response we have received from their technician is as follows: > > "Okay, this is making some sense now. We are not logging your requests > because you are not reaching us. Your software is bailing out ahead of time > because you are using Java. Java has static lists included of valid > certificate authorities. Because we only issue certificates for personal > security reasons, we are not a valid certificate authority in Java's eyes. > This causes Java to have a fatal error at the handshake: > > main, SEND TLSv1 ALERT: fatal, description = certificate_unknown > > There are two ways around this: > 1) Don't use java. Generate a new CSR, I will immediately sign it and send > it back to you. Use command line scripting or other programming languages to > communicate with our servers ( perl, curl, bash, etc...) > 2) Write your own extended SSL verification classes. We have generated an > example of how do go about this which you will find attached. Feel free to > use any parts of the code to aid in the incorporation into your system. > > If there is anything else I can do, please let me know." > > In answer to your questions, it appears as if we are never reaching them. > > I will find out the answer to your second question. > > However, your third question is very perplexing. Are there SSL modules that > do NOT work with JSSE? Wouldn't that be an open standard? > > Lukas > > > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 09, 2004 3:18 PM > > To: Commons HttpClient Project; Lukas Bradley > > Subject: Re: HttpClient Consultant Needed Immediately > > > > Lukas, > > > > First of all, you need to know if your application actually hits the > > server. It is pointless to troubleshoot the problem on the client side > > if the request never reaches the server. > > > > (1) What you tried trusting any certificate / disabling server > > certificate validation? > > (2) What is the target web server / SSL module? > > (3) Is the target server / SSL module known to work with SUN's JSSE at > > all? > > > > Oleg > > > > On Wed, 2004-06-09 at 20:07, Lukas Bradley wrote: > > > Hi all, > > > > > > > > > > > > I need a developer or consultant familiar with SSL using certificate > > > authentication within HttpClient. My company has utterly failed in > > > our attempt to interface with a financial processing gateway. > > > > > > > > > > > > Our needs are quite simple: import the processor's certificate, > > > connect via SSL using Java, and sent HTTPS traffic. It appears as if > > > our traffic isn't even reaching their servers. > > > > > > > > > > > > main, SEND TLSv1 ALERT: fatal, description = certificate_unknown > > > > > > > > > > > > We have attempted to write our own X509KeyManager and > > > X509TrustManager, as well as other recommended "hacks" from various > > > sources. I've also attached an explanatory email we sent to their > > > technical support detailing the problem. > > > > > > > > > > > > At this point, the answer may be simple, or complex. Nonetheless, I > > > think we have exhausted our options on the Java front, and need > > > expertise in this field. > > > > > > > > > > > > Please contact me as soon as possible regarding this need. If you > > > want to offer free advice, I'm very open. However, I'm more than > > > willing to pay you for your time. I'm available at lukas at somnia > > > dot com, or at 404.581.9973. > > > > > > > > > > > > Thanks for your time. > > > > > > > > > > > > Lukas Bradley > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: commons-httpclient-dev- > > [EMAIL PROTECTED] > > > For additional commands, e-mail: commons-httpclient-dev- > > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-httpclient-dev- > > [EMAIL PROTECTED] > > For additional commands, e-mail: commons-httpclient-dev- > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > 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]
