Menu
▾
▴
RE: [ebxmlms-general] RE: RE: RE: SSLHandshakeException (SSL PROBLEM) (Pattiarachi, Mal)
|
From: Pattiarachi, M. <Mal...@ro...> - 2005-08-11 00:38:55
|
Hmmm, I thought that the Apache HttpClient still used Sun's JSSE as the underlying library? I'm more than happy to be proved wronged however - = if anyone can point to a plug-in replacement for Sun's JSSE, I'll = definately try it. Sincerely, Mal -----Original Message----- From: ebx...@li... [mailto:ebx...@li...] On Behalf Of Ronald = van Kuijk Sent: Thursday, 11 August 2005 3:49 AM To: ebx...@li... Subject: Re: [ebxmlms-general] RE: RE: RE: SSLHandshakeException (SSL PROBLEM) (Pattiarachi, Mal) replace the sun impl with the apache httpclient one. Much better, = faster, M$ proxy support etc. Ronald Robert A. Stockfleth probeerde me het volgende duidelijk te maken: > I am able to connect to the Cyclone server using the simple=20 > HTTPSClient below. I am almost positive that the handshaking problem=20 > - it isn't a problem with Hermes, more like with the=20 > HttpsURLConnection class which Hermes utilizes. > > I would file a bug report with Sun - but unless I can give them access = > to our trading partner's development environment - I have no way to=20 > replicate the issue for them. So I am pretty much out of luck. > > If anybody comes up with a work-around - I would LOVE to hear about=20 > it. > > Thanks, > > -Rob > > > -----Original Message----- > From: ebx...@li... > [mailto:ebx...@li...] On Behalf Of=20 > ebx...@li... > Sent: Tuesday, August 02, 2005 8:15 PM > To: ebx...@li... > Subject: ebxmlms-general digest, Vol 1 #276 - 3 msgs > > Send ebxmlms-general mailing list submissions to > ebx...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > or, via email, send a message with subject or body 'help' to > ebx...@li... > > You can reach the person managing the list at > ebx...@li... > > When replying, please edit your Subject line so it is more specific=20 > than "Re: Contents of ebxmlms-general digest..." > > > Today's Topics: > > 1. RE: SSLHandshakeException (SSL PROBLEM) (Robert A. Stockfleth) > 2. RE: RE: SSLHandshakeException (SSL PROBLEM) (Pattiarachi, Mal) > 3. Re: RE: SSLHandshakeException (SSL PROBLEM) (David Webber (XML)) > > --__--__-- > > Message: 1 > From: "Robert A. Stockfleth" <ro...@no...> > To: <ebx...@li...> > Date: Tue, 2 Aug 2005 15:05:00 -0700 > Subject: [ebxmlms-general] RE: SSLHandshakeException (SSL PROBLEM) > Reply-To: ebx...@li... > > This is a multi-part message in MIME format. > > ------=3D_NextPart_000_001F_01C59773.8DC924D0 > Content-Type: text/plain; > charset=3D"us-ascii" > Content-Transfer-Encoding: 7bit > > A few weeks ago I figured out where my SSL Handshake problem is coming = > from. > > > > It seems that by default Hermes uses the HttpsURLConnection class to=20 > connect (when you're accessing a HTTPS URL). > > > > I rewrote the SSL connection portion of Http.java to use the Socket=20 > class instead of the HttpsURLConnection class. When I connected using = > the exact same keystore - the handshaking process worked properly. > > > > It seems like something inside the HttpsURLConnection class was not=20 > compatible with the Cyclone server, my private key or both. > > > > Anyone have any ideas (that don't involve hacking the source apart)?? > > > > PS Any chance future versions of Hermes will undergo Drummond's=20 > "EBXML" certification. Many large companies will not allow outside=20 > vendors to connect, unless they are using an officially EBXML=20 > certified application. > > > > Message: 2 > From: "Pattiarachi, Mal" <Mal...@ro...> > To: <ebx...@li...> > Subject: RE: [ebxmlms-general] RE: SSLHandshakeException (SSL PROBLEM) > Date: Wed, 3 Aug 2005 09:30:57 +1000 > Reply-To: ebx...@li... > > This is a multi-part message in MIME format. > > ------_=3D_NextPart_001_01C597BA.3BDDD192 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=3D"iso-8859-1" > > Hi Robert, > > I'm getting a similar error (javax.net.ssl.SSLHandshakeException:=20 > Remote host closed connection during handshake) at random occassions=20 > (some connections get through), when connecting to Tibco Business=20 > Connect in =3D our partners test environment. Oddly enough, in=20 > production, where our =3D partner > uses an external clustered HTTPS web server, the connections appear to = =3D > work > fine. > > The thing is, the problem is replicable outside of Hermes... i.e. I=20 > used =3D a simple HTTPS client (consisting of just a few lines of = code)=20 > which uses =3D the > socket method of connecting, and I still got the same error I'm = getting =3D > with > Hermes ... and this was duplicated no matter the version of Java I was > using, be it 1.4.2_01 or 1.4.2_08 or 1.5! I figured this was a problem = =3D > to do > with Tibco's internal SSL handler which wasn't behaving correctly and > requested our partner try to see what's going on with Tibco. > > We use Hermes 0.9.3.1 and Java 1.4.2, I examined Http.java - most if=20 > it appears to be commented out? Perhaps it's changed between versions. > > I've attached the source code I was using for the simple HTTPS client, = > =3D see if you can connect to your partners Cyclone using it.=3D20 > > > > import java.net.*; > import java.io.*; > import java.security.*; > import javax.net.ssl.*; > > public class HTTPSClient { > > public static void main(String[] args) { > > > > int port =3D3D 6707; > String host =3D3D "HOST_URL"; > > try { > > Security.addProvider(new = com.sun.net.ssl.internal.ssl.Provider()); > SSLSocketFactory factory > =3D3D (SSLSocketFactory) SSLSocketFactory.getDefault(); > > SSLSocket socket =3D3D (SSLSocket) factory.createSocket(host,=20 > port); > > > > Writer out =3D3D new = OutputStreamWriter(socket.getOutputStream()); > // https requires the full URL in the GET line > out.write("GET http://" + host + "/ HTTP/1.1\r\n"); > out.write("\r\n"); > out.flush(); > > // read response > BufferedReader in =3D3D new BufferedReader( > new InputStreamReader(socket.getInputStream())); > int c; > while ((c =3D3D in.read()) !=3D3D -1) { > System.out.write(c); > } > > out.close(); > in.close(); > socket.close(); > > } > catch (Exception e) { > System.out.println(e); > } > > } > > } > > > > > > -----Original Message----- > From: ebx...@li... > [mailto:ebx...@li...] On Behalf Of=20 > Robert =3D A. Stockfleth > Sent: Wednesday, 3 August 2005 8:05 AM > To: ebx...@li... > Subject: [ebxmlms-general] RE: SSLHandshakeException (SSL PROBLEM) > > > A few weeks ago I figured out where my SSL Handshake problem is coming = > =3D from. =3D20 > It seems that by default Hermes uses the HttpsURLConnection class to = =3D > connect > (when you're accessing a HTTPS URL). > =3D20 > I rewrote the SSL connection portion of Http.java to use the Socket = =3D > class > instead of the HttpsURLConnection class. When I connected using the = =3D > exact > same keystore - the handshaking process worked properly. > =3D20 > It seems like something inside the HttpsURLConnection class was not > compatible with the Cyclone server, my private key or both. > =3D20 > Anyone have any ideas (that don't involve hacking the source apart)?? > =3D20 > PS Any chance future versions of Hermes will undergo Drummond's = "EBXML" > certification. Many large companies will not allow outside vendors to > connect, unless they are using an officially EBXML certified =3D > application. > =3D20 > > The information contained in this email and any attachments to it: = =3D20 > (a) may be confidential and if you are not the intended recipient, any = =3D > interference with,=3D20 > use, disclosure or copying of this material is unauthorised and =3D > prohibited; and > =3D20 > (b) may contain personal information of the recipient and/or the = sender =3D > as defined > under the Privacy Act 1988 (Cth). Consent is hereby given by the =3D > recipient(s) to=3D20 > collect, hold and use such information and any personal information = =3D > contained in a=3D20 > response to this email, for any reasonable purpose in the ordinary =3D > course of=3D20 > Ross Human Directions Limited business (including all of it=3D92s =3D > subsidiaries), including=3D20 > forwarding this email internally or disclosing it to a third = party.=3D20 > All personal information collected by Ross Human Directions Limited = will =3D > be handled in=3D20 > accordance with Ross Human Directions Limited Privacy Policy. If you = =3D > have received this=3D20 > email in error, please notify the sender and delete it.=3D20 > > (c) you agree not to employ or arrange employment for any candidate(s) = > =3D supplied in=3D20 this email and any attachments without first = entering=20 > into a contractual =3D agreement with=3D20 > Ross Human Directions Limited. You further agree not to divulge any = =3D > information contained=3D20 > in this document to any person(s) or entities without the express =3D > permission of=3D20 > Ross Human Directions Limited.=3D20 > > Message: 3 > From: "David Webber \(XML\)" <da...@dr...> > To: <ebx...@li...> > Subject: Re: [ebxmlms-general] RE: SSLHandshakeException (SSL PROBLEM) > Date: Tue, 2 Aug 2005 22:25:25 -0400 > Organization: XML eBusiness > Reply-To: ebx...@li... > > This is a multi-part message in MIME format. > > ------=3D_NextPart_000_00F1_01C597B1.145CD180 > Content-Type: text/plain; > charset=3D"iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Robert, > > Good catch. > > On the certification front. I've done the Drummond testing with a =3D = > commercial product. > > I would venture that if Hermes can freely interchange with the target=20 > =3D server (say Cyclone - which BTW has probably the most complete =3D > implementation) - that is exactly like completing the Drummond testing = > =3D anyway. > > Of course Drummond makes you perform a range of tests with four or=20 > more =3D other vendors - but you can easily verify that Hermes matches = > those =3D needs. > > BTW - the CPA handling in current Hermes is not all it should be. My=20 > =3D understanding that is being enhanced - along the lines we did in = the=20 > =3D code here - http://ebxmlbook.com/interop/=3D20 > > All this is about verifying the operation. For example - Oracle now=20 > has =3D a ebMS compatible server to for iHub - but its not "certified" = -=20 > and =3D I'll wager that your management would happily use it, eh? > > Hope that helps your decision making. > > Thanks, DW > _______________________________________________ > ebxmlms-general mailing list ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > > > End of ebxmlms-general Digest > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing = & QA > Security * Process Improvement & Measurement * = http://www.sqe.com/bsce5sf > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > --=20 Kijk niet terug, maar kijk naar mij Against all odds ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle = Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & = QA Security * Process Improvement & Measurement * = http://www.sqe.com/bsce5sf _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general The information contained in this email and any attachments to it: =20 (a) may be confidential and if you are not the intended recipient, any = interference with,=20 use, disclosure or copying of this material is unauthorised and = prohibited; and =20 (b) may contain personal information of the recipient and/or the sender = as defined under the Privacy Act 1988 (Cth). Consent is hereby given by the = recipient(s) to=20 collect, hold and use such information and any personal information = contained in a=20 response to this email, for any reasonable purpose in the ordinary = course of=20 Ross Human Directions Limited business (including all of it=92s = subsidiaries), including=20 forwarding this email internally or disclosing it to a third party.=20 All personal information collected by Ross Human Directions Limited will = be handled in=20 accordance with Ross Human Directions Limited Privacy Policy. If you = have received this=20 email in error, please notify the sender and delete it.=20 (c) you agree not to employ or arrange employment for any candidate(s) = supplied in=20 this email and any attachments without first entering into a contractual = agreement with=20 Ross Human Directions Limited. You further agree not to divulge any = information contained=20 in this document to any person(s) or entities without the express = permission of=20 Ross Human Directions Limited.=20 |
