Back to Blog Archive

Configuring HTTPS in Mule 3.6+

Posted on: August 25, 2015
Author:
Gabriel

 

In an earlier post, we showed how to configure an HTTPS client and server flows in Mule. That post remains valid when using the ‘old’ HTTP connector, but this has now been deprecated in Mule 3.6+. Configuring HTTPS using the new listener and requester in Mule are more straightforward in my opinion. This post shows how to configure one-way SSL  and mutual authentication (two-way SSL) by giving both client and server example flows in Mule.

Note, all key stores and trust stores in this example have been generated using keystore explorer which is a very handy graphical alternative to the Java keytool. All key/trust stores were created using the RSA algorithm and JKS format.

One-way SSL

The following snippet shows how to configure an HTTPS listener and requester for one-way SSL. The key store of the listener (server) contains the public certificate and private key. The trust store of the requester (client) contains the public certificate of the HTTPS listener. Note that we only need to configure a key store on the listener and a trust store on the requester.

Read more: “What Is An SSL Certificate And Why You Should Care” by pixelprivacy.com

Mutual Authentication

For mutual authentication we need to configure both client and server connectors using a key store and a trust store. Let’s take a look at what each of these should contain.

The HTTPS listener again holds a reference to the keystore which stores the public self-signed certificate and private key. In addition, we reference the server trust store which stores the certificates of client applications which it should trust.

The HTTPS request config references the client trust store (same as when we set up one-was SSL, this holds the certificate of the HTTPS server). This time we also specify a client keystore that includes a public certificate and private key which belongs to the client.

To test the flows, simply send an HTTP GET request to the URLs: http://localhost:8081/oneWaySSL or http://localhost:8081/mutualAuth. Note; you will need to add an HTTP listener to the application. Go here for a working example including test key and trust stores. Below is the expected console output:

Thanks for reading this post, I hope you have found it informative and useful! 🙂

 

Author:
Gabriel

9 Comments for “Configuring HTTPS in Mule 3.6+”

  1. D.Rajeshkumar says:

    good article and usefull information on authentication

  2. Meva DODO says:

    Good post,
    Case Oneway-ssl: if the client is not a Mule flow, how does it do to connect to Mule Server ?
    Your example is just a flow client ? What configuration is to do ?

    • Alan Cassar says:

      This will depend completely on your client. If your client is a browser, putting https:// in the address bar will active automatically the HTTPS ‘mode’. If you are using a self signed certificate, the browser will tell you that this is not a safe site and you can continue at your own risk. If you are using a signed certificate, the browser simply goes ahead and hits your Mule flow.

      If you have a normal Java client and you are using a self signed certificate, you might need to import the certificate into your keystore to configure it as a trusted certificate.

      Hope this helps.

  3. srikanth says:

    does “client-truststore” is a reserved word or how this name came?

    • Mario says:

      Hello Srikanth,

      Are you referring to :

      -- tls:trust-store path="client-truststore" password="mulepass" type="jks" ---

      If yes, thats the location of your “truststore” file containing your client keystore. I can give you another example:

      < http:request-config name="HTTPSecureRequest" host=".." port=".." doc:name="HTTP Request Configuration" protocol="HTTPS">

      < tls:context>
      < tls:trust-store path="serverStore.jks" password=".." type="jks" />
      < tls:key-store type="jks" path="myClientStore.jks" alias=".." keyPassword=".." password=".." />
      < /tls:context>

      < /http:request-config >

      Hope this answer will help you.

      Regards,
      Mario.

  4. This is super useful. Thanks for sharing!

  5. Kevin says:

    Shouldn’t your test be making https calls ?

    https://localhost:8081/oneWaySSL and https://localhost:8081/mutualAuth.

    • Juergen says:

      The listening flows listening on /oneWaySSL and /mutualAuth are using the standard HTTP through httpServerConnector. The flow that is protected by SSL is the one listening on /httpsServer.

      Hope this helps.

      Regards,

      Juergen

  6. mani says:

    could you please provide the command to create
    client-keystore
    client-truststore
    server-keystore
    server-truststore

Comments

Contact Us

Ricston Ltd.
Triq G.F. Agius De Soldanis,
Birkirkara, BKR 4850,
Malta
MT: +356 2133 4457
UK: +44 (0)2071935107

Send our experts a message

Need Help?
Ask our Experts!