[jbossts-issues] [JBoss JIRA] Commented: (JBTM-347) Make sure XTS works with HTTPS
Andrew Dinn (JIRA)
jira-events at lists.jboss.org
Thu Feb 5 09:22:44 EST 2009
[ https://jira.jboss.org/jira/browse/JBTM-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12451302#action_12451302 ]
Andrew Dinn commented on JBTM-347:
Ok, so I have enabled use of https for all XTS messages when using the WS-TX 1.1 protocols.
This requires enabling of the secure HTTP port in any JBoss AS which is running either an XTS client, an XST participannt (web service) or the XTS coordinator. It also requires setting up a keystore and truststore to allow secure communications using SSL.
Secure communication is switched on by specifying an XTS coordinator URL with an https scheme. The usual XTS 1.1 coordinator endpoint address is
where <bindhost> is the bind address supplied as a parameter on the JBoss AS run.sh/run.bat command line using the -b flag (<bindhost> defaults to localhost if this parameter is not supplied).
If the client is run in an AS which specifies the coordinator URL as
then the initial client<-->coordinator exchange at transaction begin and all subsequent XTS message exchanges between client<-->coordinator and participant (web service)<-->coordinator will employ https.
The coordinator URL can be reset in a variety of ways and this fix has changed the behaviour slightly. One option is to set system properties, either for the whole URL
if unset then the components properties are tested for and used to construct a URL
or, in case that is unset, by specifying individual components of the URL
value should be http/https and defaults to http
defaults to <bindhost>
defaults to jbossweb http port (normally 8080) if scheme is http and
jbossweb secure http port (normally 8443) if scheme is https
defaults to ws-c11/ActivationService
If none of these system properties is set then the URL is obtained from the value of property org.jboss.jbossts.xts11.coordinatorURL which is specified in property file wstx11.xml which can be found in
config.jar in the deployed jbossxts.sar. Edits to this file take effect the next time the XTS service is deployed.
n.b. just for the record because configuration was not straightforward
in order to test this with client, participants and coordinator all located on localhost I had to create a keystore and truststore in the server conf directory and modify the jbossweb server.xml to enable the secure HTTPS port using SSL. The former was done by executing
keytool -genkey -keystore server/default/conf/test.keystore -storepass test -keyalg RSA -keysize 1024 -validity 1000 -alias localhost -dname "CN=localhost"
keytool -export -keystore server/default/conf/test.keystore -storepass test -alias localhost -file server/default/conf/localhost.cer
keytool -import -keystore server/default/conf/wsse.truststore -storepass jbossws -trustcacerts -alias localhost -file server/default/conf/localhost.cer
The latter was achieved by uncommenting the SSL secure port declaration in server/default/deploy/jbossweb.sar/server.xml and pointing it at the relevant store files:
<!-- SSL/TLS Connector configuration using the admin devl guide keystore
<Connector protocol="HTTP/1.1" SSLEnabled="true"
scheme="https" secure="true" clientAuth="false"
sslProtocol = "TLS" />
When running the AS the following JAVA_OPTS settings were required to
enable use of https in the coordinator URL
point the remoting code at the relevant key and trust stores
ensure that the client side of an XTS exchange did _not_ try to validate the hostname in the certificate returned form the XTS server side of the exchange.
export JAVA_OPTS="-Dorg.jboss.jbossts.xts11.coordinator.scheme=https \
The last property (ignoreHttpsHost) was required because the entry for the loopback address 127.0.0.1 in /etc/hosts contained localhost.localdomain and localhost as aliases _in that order_. This meant that the wrong hostname was being used to verify the server certificate address/hostname. If localhost is placed before localhost.localdomain in /etc/hosts then the last property can be left undefined and the truststore check works ok.
> Make sure XTS works with HTTPS
> Key: JBTM-347
> URL: https://jira.jboss.org/jira/browse/JBTM-347
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: WS-T Implementation
> Reporter: Mark Little
> Assignee: Andrew Dinn
> Priority: Critical
> Fix For: 4.6
> WS-TX 1.1 recommended (though did not mandate) HTTPS for the "transport". For interoperability, HTTPS cannot be mandated, but some implementations (e.g., MSFT) don't have an "off switch" and won't work unless HTTPS is used. Yes, this breaks interoperability, but it's unlikely to change. We need to make sure that we can work successfully with HTTPS and MSFT.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues