Enabling Custom SSL Profiles in WSO2 ESB 4.8.1

Enabling Custom SSL  Profiles in WSO2 ESB 4.8.1

In my previous post I explained about the SSL Handshake and about the mutual SSL Handshake. In WSO2 ESB it supports secure communication with a back end service via SSL.

Use Case

Before go in to setting up the environment for SSL , it would be easier to understand if we consider the use case scenario. In this scenario we have a client, ESB Proxy service and a back end service which we are going to communicate with. In this post I am using a simple echo service which is available in WSO2 DSS 3.1.1 . 
To communicate with SSL we need to have two main things.
  1. A key store
  2. A trust store
The key store is for generating public and private keys for hosts and the trust store is for storing trusted key stores' information(for validation).

STEP 1:
Deploy a service in a server (In this example I use WSO2 DSS and the echo service is used as the service)

STEP 2:
Create a Proxy service in WSO2 ESB to the DSS eco service endpoint.

STEP 3:
Create a Custom SSL Profile to the echo service.

Implementation

          In WSO2 ESB we can set custom SSL Profiles by editing the axis2.xml configuration file. You can find this file in CARBON_HOME/repository/conf/axis2/axis2.xml location. In this file you can find an entry called <transportsender></transportsender>. We ca add our custom profiles inside this tag as follows. Inside this tag resides the default configuration and you need to comment it before creating the custom profiles. One of the greatest advantages in WSO2 ESB is that, it allows you to create more than one custom profiles for different hosts+ports combinations. Bellow is the configuration for creating two custom SSL Profiles.

<transportSender name="https" class="org.apache.synapse.transport.passthru.PassThroughHttpSSLSender">        <parameter name="non-blocking" locked="false">true</parameter>
        <parameter name="customSSLProfiles">
            <profile>
                <servers>10.100.4.80:9445</servers>
                <TrustStore>
                    <Location>path/to/trust-store</Location>
                    <Type>JKS</Type>
                    <Password>xxxxxx</Password>
                </TrustStore>
            </profile>

            <profile>
                <servers>10.100.4.80:9446</servers>
                <KeyStore>
                    <Location>path/to/keystore</Location>
                    <Type>JKS</Type>
                    <Password>xxxxxx</Password>
                    <KeyPassword>xxxxxx</KeyPassword>
                </KeyStore>
                <TrustStore>
                    <Location>path/to/trust-store</Location>
                    <Type>JKS</Type>
                    <Password>xxxxxx</Password>
                </TrustStore>
            </profile>
        </parameter>

    </transportSender>


In the above configuration I have two profile entries, one for my DSS echo service and the other for my Application Server echo service. In the first profile entry I have used only the trust store. Therefore it is enabled to work with usual SSL Handshake, in which only the server is authenticated by the client. In the second profile I have both trust store and a key store. This allows for mutual SSL Handshake, in which the server also need to authenticate the client.

To work this scenario correctly your trust store should have an entry to your server's key store, saying that you can trust the server. To avoid confusion please be noted that the key store entry is not the key store of server's key store, this entry is the client's key store which is used to generate the public keys and private keys for the client

For this scenario I created two key stores in the server side (Say ks1 and ks2) and only one of them (Say ks1) imported to the trust store of the client side. When you use ks1 in the server side, you can successfully communicate with the echo service. If you change you key store to ks2 then the client cannot authenticate the server since the client's trust store does not have an entry for ks2.

You can follow this detailed blog post for creating key stores, changing key store in server side and importing key stores to a trust stores.

If you successfully configured the SSL Profiles, you can see a log in the terminal as bellow

[2014-03-23 11:55:19,298]  INFO - ClientConnFactoryBuilder HTTPS Loading Trust Keystore from : repository/resources/security/client-truststore.jks
[2014-03-23 11:55:19,304]  INFO - ClientConnFactoryBuilder HTTPS Loading Identity Keystore from : repository/resources/security/wso2carbon.jks
[2014-03-23 11:55:19,310]  INFO - ClientConnFactoryBuilder HTTPS Loading Trust Keystore from : repository/resources/security/backup_client-truststore.jks
[2014-03-23 11:55:19,370]  INFO - DeploymentInterceptor Deploying Axis2 service: echo {super-tenant}
[2014-03-23 11:55:19,371]  INFO - ClientConnFactoryBuilder HTTPS Custom SSL profiles initialized for 2 servers

[2014-03-23 11:55:19,620]  INFO - DeploymentEngine Deploying Web service: Echo.aar - file:/home/nadeeshaan/WSO2/SSL_PROJ/wso2esb-4.8.1/repository/deployment/server/axis2services/Echo.aar






Comments

Popular posts from this blog

Using WSO2 ESB HTTP Endpoints to define Restful Endpoints

Integrating WSO2 ESB Connectors in real world integration Scenarios