On Wednesday 14 July 2010 1:29:48 pm David Valeri wrote: > I looked into it some more and here is what I have for default behavior for > loading a WSDL over HTTPS: > > An <http:conduit> configuration in the context is looked up using the WSDL > URL minus any URL parameters. So a WSDL located at > https://localhost:8443/service/myservice?wsdl will end up trying to locate > a configuration with ID "https://localhost:8443/service/myservice";. > > Wildcards are enabled during this lookup so the bean name can use wildcards > to match just like when configuring the conduit for service invocations > using the ".http-conduit" suffix. > > A configuration for WSDL retrieval at the above WSDL URL would look like: > > <http:conduit name="https://localhost:8443/service/myservice";> > ... > </http:conduit> > > I don't believe this is documented anywhere so I will make a point of > getting it into the client HTTP configuration documentation. >
it is kind of mentioned at: http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html in the first section. Possibly not very clear though. Dan > > -----Original Message----- > From: David Valeri [mailto:[email protected]] > Sent: Wednesday, July 14, 2010 12:25 PM > To: [email protected] > Subject: RE: writing SSL webservice client > > This is actually an interesting question as I am working my way through > similar scenarios right now. Odds are that it worked with the public Web > service because Thawte is a big commercial CA and is already included in > the cacerts file. I think that if you do not provide any trust managers > on the client side, you get trust from cacerts. > > The fact that your second scenario worked is different than my current > experience when trying to retrieve the WSDL, but not for actual service > invocation. The configuration you list is fine for production use if you > do the following, encrypt/obfuscate the password value in a properties > file and read it in using Jasypt. Jasypt extends Spring's property > placeholder capability to support encrypted property values in property > files or you can simply lock the file down such that read access is > limited using your OS. The approach you have to take just depends on your > program's security requirements. > > Did you also retrieve the WSDL over SSL in your second scenario or did you > load it from the classpath or file system when you created the client? The > experience I am seeing is that the WSDL resolution into an InputStream > never happens until deep inside Xerces at which point we are basically > opening an InputStream on a URL using the default JVM JSSE configuration. > There are a couple attempts to resolve the URL using URLResource but they > of course all fail because of the custom PKI so the InputSource that is > provided to Xerces only has a SystemId and no InputStream. > > Is there a way in CXF to force WSDL resolution to use the client TLS config > on the Bus? I seem to remember seeing this happen with > TransportURIResolver, but the current behavior I am seeing causes the > Configurer to not try configuring the HttpConduit because the bean name is > null. I have just started to debug this behavior, so any pointers would be > much appreciated. > > > -----Original Message----- > From: siva naresh [mailto:[email protected]] > Sent: Wednesday, July 14, 2010 1:41 AM > To: [email protected] > Subject: Re: writing SSL webservice client > > > I also tried an example locally, Where I generated certificates using > keytool > for the server > and used the same certificate to invoke the server from the client > using trustmanager in the following way. > > <sec:trustManagers> > <sec:keyStore type="JKS" password="password" > file="truststore.jks"/> > > it worked fine. But this is not for the production use. What changes do I > need to make for production use ? > > what is the way to put the server's public key in the client JDK's cacerts > file. Does CXF has anything to make this automatically? > > Does CXF verify the authenticity of the server's public key with the CA? -- Daniel Kulp [email protected] http://dankulp.com/blog
