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
