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.*
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_Security__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/src >>> >/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 >> >> > > -- View this message in context: http://www.nabble.com/Http-conduit-disableCNCheck-tp20444655p20467179.html Sent from the cxf-user mailing list archive at Nabble.com.
