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-tp20444655p20449170.html Sent from the cxf-user mailing list archive at Nabble.com.
