Thursday, January 16, 2014

Accessing a non secured backend from a secured client with the help of WSO2 ESB

Assume that you have a backend that is not secured and you need to invoke this with a secured client. The below configuration is of a Proxy service which talks to a non secured backend. The client used to invoke this proxy service is secured. In this particular scenario, the Proxy service is secured.


Download WSO2 ESB 4.8.0 from here. Extract it to a folder of your choice and start the server.
Download the StockPurchasingService.aar from here and deploy it in a application server of your choice.

Testing out the scenario

When the message sent from the client is secured and the backend service is not, you need to ensure that the security headers are removed from the message before it is being sent from ESB to the backend. By using the header mediator as below, we can remove the security headers.

Step 1

Deploy the following proxy service in WSO2 ESB. <?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns=""
         <header xmlns:wsse=""
         <address uri="http://localhost:9773/services/PuchasingService"/>
   <publishWSDL uri="http://localhost:9773/services/PuchasingService?wsdl"/>

We will test our scenario with security scenario 2 (Non-repudiation). Once the above proxy service is deployed, apply security scenario 2 from the wizard.  View the ?wsdl of the proxy service and verify whether the relevant policy is attached to the proxy service.
One the security policy is applied, the complete proxy service configuration will look like what is available here.

Step 2

Create a Java project from your favourite IDE and place the & files in the below structure.

└── src
Note: Download the folder and extract the content to the src level. Then set the paths of following fields of the file accordingly.
  • clientRepo
  • clientKey
  • securityPolicyLocation
  • trustStore

Step 3

Invoke the code and you will get the expected response message as below.

Result :1000
Scenario No :2

Result : >ns:purchaseresponse xmlns:ns=""<>ns:return<1000>/ns:return<>/ns:purchaseresponse<

Friday, January 3, 2014

How to solve "PKIX path building failed: unable to find valid certification path to requested target" issue of WSO2 Products

Ever come across the error message mentioned in the subject while trying out WSO2 products? Well, if you have, the reason is that cetifacte of the backend that you is not trusted and the certificate of that backend server should be added to the WSO2 product servers client-truststore.jks. Lets try this with a simple example.

Assume you have a simple API with the below configuration pointing to twitter search in WSO2 ESB (You can try this with a latest version of ESB). The configuration will be as follows.

      <api name="TwitterAPI" context="/twitter">
      <resource methods="GET" url-mapping="/*">
                  <address uri=""/>

Invoke the above API using the below command.

curl -v -X GET -H "Content-type: application/json" http://localhost:8281/twitter/search?q=wso2

It will throw the below exception at the WSO2 ESB server console.

Caused by: PKIX path building failed: unable to find valid certification path to requested target
    ... 17 more
Caused by: unable to find valid certification path to requested target
    ... 23 more

Inorder to get rid of this exception and the request to passthrough successfully to the backend, you need to import the public certificate of Twitter to the client-truststore.jks of the WSO2 ESB server instance. Below are the steps you need to follow.

1. Go to, click on the lock icon at the address bar, click on the 'Connection' tab, then click on the link 'Certificate Information'. From the 'Certificate Viewer', select the tab 'Details' and click on the 'Export' button and download the certificate ( to a preferred location.

2. Once downloaded, issue the below command to import the public certificate of Twitter to the client-truststore.jks.

$ keytool -importcert -file $somepath/ -keystore $ESB_HOME/repository/resources/security/client-truststore.jks -alias "Twitter"

3. Restart the WSO2 ESB server and invoke the API again and you will get the expected result.