On Wednesday 19 November 2008 1:30:59 pm wonderingWV wrote:
> 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?Normally, it's about every 2 months or so. However, we released 2.1.3 on Oct 22. That would put the next right at Christmas time which might not be the best option. I'm not sure if we want to move it up to maybe Dec 10th-15th or so or move it out to the first week of Jan. Anyone have any thoughts? Dan > > 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_Secu > >>r > >> > >> >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 -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
