Monday, October 28, 2013

WSO2 ESB exposing a secure backend through a proxy.

(Special thanks goes to Sumedha Kodithuwakku @ wso2 support team)


In this post i will describe how to generate a custom certificate using keytool and use that certificate to secure a your web service and finally how to expose the secured web service using a proxy in wso2 ESB.



1. Generate a custom certificate.


Open a command prompt and use the keytool to generate a certificate. Here I use the CN as localhost since we use locally host web service(keep this in mind for later use). The rule of thumb is that CN should be matches to the hostname of the wsdl endpoint to resolve it by the ESB.


(Also using IP address as a CN would be a problematic so always stick to a host name rather than using an IP address.)


Use the following command to generate a certificate


keytool -genkey -alias localhost -keyalg RSA -keystore localhost.jks


*** When asked for the first and last name give the hostname which is localhost in our case.


Here you can use what ever name for -alias and - localhost.jks which is the alias of our certificate and name of the keystore if it newly create.


then export that certificate to a “.crt” file using command below.


keytool -export -alias localhost -file localhost.crt -keystore localhost.jks


2 Adding a keystore to web server (tomcat in our example)


Open the server.xml file in <tomcat-location>/conf/ folder and edit the <Connector port=”8443”tag as below.


<Connector port=”8443” protocol=”HTTP/1.1” SSLEnabled=”true”
               maxThreads=”150” scheme=”https” secure=”true”
               clientAuth=”false” sslProtocol=”TLS”
               keystoreFile=”C:\keyStores\localhost.jks” keystorePass=”123456” />


Here we have added the keystore and the password we newly created.


3. Adding imported certificate to wso2 keystore and truststore.


Browse to <wso2-esb>\repository\resources\security folder. There is two keystore files namely “client-truststore.jks” and “wso2carbon.jks”. Use the below command to add the newly created and stored certificate (localhost.crt as our example in part 1 ) to these two keystore. Provide alias as the host name used as CN.



keytool -importcert -v -trustcacerts -file “localhost.crt” -alias localhost -keystore “wso2carbon.jks”


keytool -importcert -v -trustcacerts -file “localhost.crt” -alias localhost -keystore “client-truststore.jks


Since we are using localhost as our host we have update “HostnameVerifier" parameter in <wso2-esb>repository/conf/axis2.xml file to allow all hosts.


<parameter name=”HostnameVerifier”>AllowAll</parameter>


(This parameter can be found in <transportSender name=”https” tags.)



4. Create a proxy as normal and add the https://localhost:8443/<your-service>?wsdl file as normally do.


Resources :


[1] http://blog.facilelogin.com/2011/02/wso2-esb-invoking-web-service-via-https.html


[2] http://stackoverflow.com/questions/8443081/how-are-ssl-certificate-server-names-resolved-can-i-add-alternative-names-using/8444863#8444863


[3] http://stackoverflow.com/questions/19540289/how-to-fix-the-java-security-cert-certificateexception-no-subject-alternative?rq=1

Wednesday, October 2, 2013

I WSO2ESB start up failed and hangout due to typo of wsdl saved in governance registry

Ok first of all i will tell what happened before the start up fail.


1. We have added a wsdl file belong to one of our services into the governance registry.


2. While manually editing the wsdl file which have been added to governance registry, some miss typing has occurred which changed a letter of one of the XML tags into upper case


3. Without knowing about the typo we saved the wsdl, (and here is the funny part… ) ESB let that wsdl to be save in it’s governance registry without parsing it or neither complaining us about the typo we did .. ( really ??? an enterprise level ESB does not check the documents edited ??? )



4. After some time for some reason we have restarted the ESB. ( and here the fun began. ) ESB hangout printing an exception complaining XML parsing error when it try to load that wsdl file where the error happened. And the admin console is not loading because OSGI module that correspond to esb (Synapsys) is waiting until all the wsdl loads. (This is the biggest fault - not letting other services, and esb to start because a wsdl typo occurred where it should parse the wsdl before save it to registry )


At the end of the console we can see the following message printed time to time without starting the ESB and the services due to what happened that has been described above.


 StartupFinalizerServiceComponent Waiting for required OSGi services: org.wso2.carbon.mediation.initializer.services.SynapseEnvironmentService


And this is the exception which complains about that our wsdl could not be parsed at startup.


WstxParsingException: Illegal processing instruction target (“xml”); xml (case insensitive) is reserved by the specs. at [row,col


There were 0 documentation and no entry about how to handle such a situation.


According to this exception we guessed the work around for this problem is just to remove the erroneous wsdl file from the governance registry. But wso2esb it self should not let that wsdl added to the registry at the first place. Even it did add, there should be some way to remove the erroneous wsdl related proxy and start up the esb and other proxy services. But it does not have that feature yet.


So how the hell we edit the governance registry without esb up.


Well, there is no proper way wso2 has exposed to do that. ( i could not find any thing on the web that’s why i write this blog entry apart from that to complement wso2 esb team about this s:D )



What we did is this,


1. Shut down the esb , copy and back up the databases folder in <wso2esb_home>/repository/database


2. Download any sql viewer tool that support h2 database management system. (yes wso2 default database is java h2 DBMS - in our case we used the default DBMS ). I used SQL Squirrel with h2 database jdbc driver.


3. open/connect to the h2 database in above folder using the sql tool.


4. find the “REG_RESOURCE” and “REG_CONTENT” tables in “WSO2CARBON_DB/PUBLIC/TABLE/” location.


5. search for erroneous wsdl file name inside “REG_RESOURCE” (hint: use sql select). File name for a resource in “REG_RESOURCE” saved in “REG_NAME” column. 


6. From the resulted row note down the value of “REG_CONTENT_ID” and search for that REG_CONTENT_ID in “REG_CONTENT” table. The resulting row is where the actual wsdl file saved as sql BLOB file type.


select rc.REG_CONTENT_ID from REG_RESOURCE rr, REG_CONTENT rc where rr.REG_NAME like ‘%mywsdl.wsdl’ and rc.REG_CONTENT_ID=rr.REG_CONTENT_ID


7. To recover the wso2 esb from hanging out due to this erroneous wsdl remove the two entries related to REG_CONTENT_ID of REG_NAME of the wsdl from two tables.


8. Re start the wso2esb and you may find that exceptions are no more there and server does not hanging out any more.



Yeah i know this is bit fishy and fundamental, but if we cant access the admin console due to that ESB not finishing up loading its OSGI module (because esb let it save error-nous wsdl inside the governance registry at the first place.) we cant do much rather than cracking the database and remove the wsdl manually right ??


PS : there may be other artifacts such as proxies, sequences, endpoints using the removed wsdl, that may affected by the removal. so i instruct to remove those of which use the removed wsdl.