The 2.1.4 SNAPSHOT corrected the issue as long as you use the workaround
suggested in the "IllegalArgumentException: SSL" thread and set
tlsParams.setSecureSocketProtocol("SSLv3") instead of just "SSL".Do you have an eta when the 2.1.4. build will be released? John dkulp wrote: > > On Wednesday 12 November 2008 2:11:22 pm wonderingWV wrote: >> If it helps, we use JDK 5 and the problem with the disableCNCheck(false) >> first appeared after we updated from CXF 2.0.* to CXF 2.1.* > > I just committed some changes that install a better HostnameVerifier to > check > the certs. It would be great if you could checkout the 2.1.x branch, > build > it, and give it a whirl. I'll try and upload new snapshots tomorrow if > doing a build is too much. > > Dan > > >> >> John >> >> Glen Mazza wrote: >> > The Metro guide seems to suggest the default verifier is a little bit >> > more intelligent than that: >> > >> https://metro.dev.java.net/guide/Security_Mechanisms.html#Transport_Secur >> >ity__SSL__Workaround >> > >> > But perhaps this is a result of switching from JDK 5 to 6? Anyway, the >> > workaround they have above probably would take care of the user >> > configurability functionality you mention in your last sentence below. >> > >> > Glen >> > >> > dkulp wrote: >> >> On Tuesday 11 November 2008 4:11:45 pm Glen Mazza wrote: >> >>> Hmmm...I'm sure I had tested that. I wonder if my 2.0.x change was >> >>> *not* >> >>> ported to the 2.1 branch? >> >> >> >> Looking back at the change history, your changes seem to add the >> >> "AlwaysTrue" >> >> verifier only if DisableCNCheck flag is true. Previous to your >> change, >> >> the >> >> AlwaysTrue verifier was always added. >> >> >> >> With your change, if the flag is false, it now delegates to the JDK >> >> built in >> >> default verifier which seems to be very stupid and just does "return >> >> false". >> >> Pretty much useless. :-( Looks to me like we need to find a good >> >> HostNameVerifier if the flag is false. Additionally, we probably >> >> should allow the user to configure in their own HostNameVerifier >> >> somehow. >> >> >> >> Dan >> >> >> >>> Glen >> >>> >> >>> dkulp wrote: >> >>> > Looking at the decompiled source for the "DefaultHostnameVerifier", >> >>> > it literally just does a "return false;". Thus, I don't see how >> >>> > it's possible >> >>> > to do any SSL things with host bound certs right now without the >> >>> > DisableCNCheck thing. It looks like we need to write a new >> >>> > HostNameVerifier thing that would actually do some level of >> >>> >> >>> verification. >> >>> >> >>> > We might be able to grab the one synapse has: >> >>> >> >>> >> http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/s >> >>>rc >> >>> >> >>> >/main/java/org/apache/synapse/transport/nhttp/HostnameVerifier.java >> >>> > >> >>> > and use that. Someone would need to check that though. That looks >> >>> >> >>> like >> >>> >> >>> > it >> >>> > came from the not-yet-commons-ssl project at >> >>> > http://juliusdavies.ca/commons-ssl/ >> >>> > >> >>> > There's probably some others floating around if we dig more. >> >>> > >> >>> > Dan >> >>> > >> >>> > On Tuesday 11 November 2008 1:10:13 pm Glen Mazza wrote: >> >>> >> If you can check the CXF source code (I don't have it with me >> >>> >> immediately, >> >>> >> but search the source code for the error message you're getting to >> >>> >> determine the class) -- you can place debugging statements on what >> >>> >> >>> CXF >> >>> >> >>> >> thinks the hostname URL and the CN is to determine why it is >> failing >> >>> >> >>> on >> >>> >> >>> >> you. Perhaps I made a mistake in my logic someplace--but as no >> one >> >>> >> >>> else >> >>> >> >>> >> has complained about this yet, I would suspect, for some reason, >> >>> >> your >> >>> >> >>> CN >> >>> >> >>> >> actually isn't matching the hostname URL. >> >>> >> >> >>> >> Glen >> >>> >> >> >>> >> wonderingWV wrote: >> >>> >> > I understand why it was done, but the problem is I cannot get >> ssl >> >>> >> >>> with >> >>> >> >>> >> > cxf to work unless the flag is set to true, which I do not want >> to >> >>> >> >>> do >> >>> >> >>> >> in >> >>> >> >> >>> >> > a production environment. >> >>> >> > >> >>> >> > Glen Mazza wrote: >> >>> >> >> I'm unsure what the problem is. I had done that last March[1] >> >>> >> >>> after >> >>> >> >>> >> >> agreement with the team. >> >>> >> >> >> >>> >> >> Glen >> >>> >> >> >> >>> >> >> [1] http://www.jroller.com/gmazza/date/20080329 >> >>> >> >> >> >>> >> >> wonderingWV wrote: >> >>> >> >>> The common name on the cert and the hostName of the url match >> up >> >>> >> >>> so >> >>> >> >>> >> >>> I not sure why I continue to receive this error. Any advise >> >>> >> >>> would >> >>> >> >>> >> >>> be greatly appreciated. >> >>> > >> >>> > -- >> >>> > Daniel Kulp >> >>> > [EMAIL PROTECTED] >> >>> > http://dankulp.com/blog >> >> >> >> -- >> >> Daniel Kulp >> >> [EMAIL PROTECTED] >> >> http://dankulp.com/blog > > > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://dankulp.com/blog > > -- View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20586228.html Sent from the cxf-user mailing list archive at Nabble.com.
