Configuring SSL Support

To configure your client to use SSL, you'll need to add an <http:conduit> definition to your XML configuration file. If you are already using Spring, this can be added to your existing beans definitions.

A wsdl_first_https sample can be found in the CXF distribution with more detail. Also, if desired, you can encrypt any temporary files created by CXF during large data stream caching -- see the CXF documentation for more details.

Here is a sample of what your conduit definition might look like:

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:sec="http://cxf.apache.org/configuration/security"
   xmlns:http="http://cxf.apache.org/transports/http/configuration"
   xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
   xsi:schemaLocation="
      http://cxf.apache.org/configuration/security
      http://cxf.apache.org/schemas/configuration/security.xsd
      http://cxf.apache.org/transports/http/configuration
      http://cxf.apache.org/schemas/configuration/http-conf.xsd
      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

   <http:conduit
      name="{http://apache.org/hello_world}HelloWorld.http-conduit">

      <http:tlsClientParameters>
         <sec:keyManagers keyPassword="password">
            <sec:keyStore type="JKS" password="password"
               file="my/file/dir/Morpit.jks"/>
         </sec:keyManagers>
         <sec:trustManagers>
            <sec:keyStore type="JKS" password="password"
               file="my/file/dir/Truststore.jks"/>
         </sec:trustManagers>
         <sec:cipherSuitesFilter>
            <!-- these filters ensure that a ciphersuite with
               export-suitable or null encryption is used,
               but exclude anonymous Diffie-Hellman key change as
               this is vulnerable to man-in-the-middle attacks -->
            <sec:include>.*_EXPORT_.*</sec:include>
            <sec:include>.*_EXPORT1024_.*</sec:include>
            <sec:include>.*_WITH_DES_.*</sec:include>
            <sec:include>.*_WITH_AES_.*</sec:include>
            <sec:include>.*_WITH_NULL_.*</sec:include>
            <sec:exclude>.*_DH_anon_.*</sec:exclude>
         </sec:cipherSuitesFilter>
      </http:tlsClientParameters>
      <http:authorization>
         <sec:UserName>Betty</sec:UserName>
         <sec:Password>password</sec:Password>
      </http:authorization>
      <http:client AutoRedirect="true" Connection="Keep-Alive"/>

   </http:conduit>

</beans>

The first thing to notice is the "name" attribute on <http:conduit>. This allows CXF to associate this HTTP Conduit configuration with a particular WSDL Port. The name includes the service's namespace, the WSDL port name (as found in the wsdl:service section of the WSDL), and ".http-conduit". It follows this template: "{WSDL Namespace}portName.http-conduit". Note: it's the PORT name, not the service name. Thus, it's likely something like "MyServicePort", not "MyService". If you are having trouble getting the template to work, another (temporary) option for the name value is simply "*.http-conduit".

Another option for the name attribute is a reg-ex expression (e.g., "http://localhost:*") for the ORIGINAL URL of the endpoint. The configuration is matched at conduit creation so the address used in the WSDL or used for the JAX-WS Service.create(...) call can be used for the name. For example, you can do:

<http:conduit name="http://localhost:8080/.*">
   ...
</http:conduit>

to configure a conduit for all interactions on localhost:8080. If you have multiple clients interacting with different services on the same server, this is probably the easiest way to configure it.

If your service endpoint uses an SSL WSDL location (i.e., "https://xxx?wsdl"), you can configure the http conduit to pick up the SSL configuration by using a hardcoded http conduit name of {http://cxf.apache.org}TransportURIResolver.http-conduit. The specific HTTP conduit name or a reg-ex expression can still be used.

Keystores (as identified by the sec:keyStore element above) can be identified via any one of three ways: via a file, resource, or url attribute. File locations are either an absolute path or relative to the working directory, the resource attribute is relative to the classpath, and URLs must be a valid URL such as "http://..." "file:///...", etc. Only one attribute of "url", "file", or "resource" is allowed.