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
