I'm still looking for a response for this. Although I'm not currently using CXF as my Soap/REST client, I'd like to know how I would configure it for this situation.
My situation is that I don't want to turn off hostname verification, but I need to alter the process. With my current code that uses HttpClient, I was able to implement something based on "jsslutils" (http://code.google.com/p/jsslutils/) that takes an alternate list of context names to compare against if the default list doesn't match (which I know I won't). I've looked through the information I can find about "http:conduit" and its sub-elements, and I don't see an obvious way to do this. > -----Original Message----- > From: KARR, DAVID (ATTSI) > Sent: Monday, May 02, 2011 11:44 AM > To: [email protected] > Subject: Can CXF's "http:conduit" be configured to deal with self- > signed certs or a custom verification? > > I don't specifically need this from CXF, but I've recently had to deal > with these issues using raw HttpClient, and I wondered what I'd have to > do to configure CXF to deal with these issues. > > Specifically, I have a project that can connect through SSL to either a > test server or a production server. On the test server, it uses a > self-signed certificate. I had to configure my HttpClient-using code > to use the "EasySSLProtocolSocketFactory", a common solution for this. > > On the production server, we ended up having to connect to the server > "under" the main server, because of network architecture issues, but > that meant that the SSL cert we were getting had a context name that > didn't match the server we were getting it from. We didn't want to > turn off hostname verification, so I implemented a different socket > factory for that scenario that can be provided with an "alternate > context name" (we provide the name of the original host we were > connecting to). > > This all works with HttpClient. If I had to, how would I implement > these features with http:conduit?
