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
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
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
<!-- 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
Make sure XTS works with HTTPS
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Components: WS-T Implementation
Reporter: Mark Little
Assignee: Andrew Dinn
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:
For more information on JIRA, see: http://www.atlassian.com/software/jira