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. -----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? -- View this message in context: http://cxf.547215.n5.nabble.com/writing-SSL-webservice-client-tp1046827p1086 015.html Sent from the cxf-user mailing list archive at Nabble.com.
