Problem with Mule cxf:outbound-endpoint (client) and HTTPS/SSL

Question

I have a small problem configuring the CXF transport in Mule 2.2 to call a WS-method on service exposed, using HTTPS/SSL. Calling the same method using plain HTTP works fine. I’ve searched a lot on this issue and found among others the following link:

http://www.mulesoft.org/documentation/display/MULE2CB/Using+HTTPS+with+CXF

which is helpful but there is still a few things that I don’t fully understand:

• The CXF endpoint is configured like: , i.e. it’s in the cxf-namespace. Does the cxf-namespace have any relation to the https-namespace for configuring the as described in the link?

• What’s even more confusing is that the Mule stuff is something I’ve taken over from a previous developer and it’s is supposedly working over SSL as-is but in the Mule config files I cannot find any trace of an https:connector configuration. From the info in the link I got the impression that it’s mandatory, at least the ”server key-store” and the “trust store”, like:

  <https:connector name="myHttpsConnector">
      <https:tls-key-store path="serverKeystore" keyPassword="mulepassword"
           storePassword="mulepassword"/>
      <https:tls-server path="trustStore" storePassword="mulepassword"/>
  </https:connector>
  

What I do get in the Mule log when trying to connect to the HTTPS-enabled WS is as below and it’s clearly related to the SSL key but I miss the last piece to get it all to fall into place. Any help and comments on this matter would be greatly appriciated.

/Ola

********************************************************************************
Message               : Failed to invoke lifecycle phase "initialise" on object:
HttpsConnector{this=a7769e, started=false, initialised=false,
name='connector.https.0', disposed=false, numberOfConcurrentTransactedReceivers=4,
createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[https],
serviceOverrides=null}
Type                  : org.mule.api.lifecycle.LifecycleException
Code                  : MULE_ERROR-70228
JavaDoc               : http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/lifecycle/LifecycleException.html
********************************************************************************
Exception stack is:
1. The Key password cannot be null (java.lang.IllegalArgumentException)
org.mule.api.security.tls.TlsConfiguration:290 (null)
2. Failed to invoke lifecycle phase "initialise" on object: 
HttpsConnector{this=a7769e, started=false, initialised=false, 
name='connector.https.0', disposed=false, numberOfConcurrentTransactedReceivers=4, 
createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[https], 
serviceOverrides=null} (org.mule.api.lifecycle.LifecycleException)
org.mule.lifecycle.DefaultLifecyclePhase:277 (http://www.mulesource.org/docs/site
/current2/apidocs/org/mule/api/lifecycle/LifecycleException.html)
********************************************************************************
Root Exception stack trace:
java.lang.IllegalArgumentException: The Key password cannot be null
    at
org.mule.api.security.tls.TlsConfiguration.assertNotNull(TlsConfiguration.java:290)
at org.mule.api.security.tls.TlsConfiguration.validate(TlsConfiguration.java:208)
...
..

Answer 1

If there are no Mule https:connector, then it could mean an external service is doing the SSL part (like a JBoss server). I have no experience doing that myself though.

But if everything is done through Mule, you also need to set the client properties (as explained in the link you mentioned):

<https:tls-client path="clientKeystore" storePassword="mulepassword" />

And to recap the various key stores (which may be confusing):

• clientKeyStore contains your client's key(s)
• serverKeyStore contains your server's key(s)
• trustStore contains the public keys of all peers, i.e. keys to clients connecting to your server, keys to any external servers (like the ws you are trying to connect to)

But the error message you got indicates that there is a missing key password. That should not happen if you have set up the key stores and the https connector properly.