7:09 a.m.
I am having a problem configuring the Web Services Transactions (XTS) code to use https
for its communications. This is a bit of an unusual situation in that XTS is implemented
as a set of services which are invoked from inside deployed apps i.e. the XTS clients are
themselves web apps running in the AS. In particular, the XTS services are made available
as JaxWS endpoints (the API layer hides the details of this from the app code of course).
Here is an example scenario to make things a bit clearer. My test case case is a web app
(the client) which begins a XTS transaction, calls a web service (the participant,
another deployed app) and then either commits or rolls back the transaction. When the
participant (web service) is called by the client it enlists in the transaction, passing a
proxy object which implements prepare, commit and rollback methods. The proxy methods are
called by the XTS implementation during handling of the client commit or rollback. All of
the operations in italics involve behind the scenes JaxWS-based communications between the
client/participant and the deployed XTS services. This use of JaxWS allows the client,
participant and XTS services to be located in different ASes. However, in my test I am
currently tackling the simplest case where they are all in the same AS.
So, for example, when the client begins the transaction JaxWS is used to talk to the XTS
Activation Service using an RPC style exchange. The Activation Service creates a
coordinator object to manage the transaction and returns a unique transaction id which
identifies the coordinator in subsequent exchanges.
I want these exchanges to use an HTTPS connection so I followed the JbossWS SSL setup
WIki page
http://www.jboss.org/community/docs/DOC-10830
and Scott's SSL Wiki page
http://www.jboss.org/community/docs/DOC-11989
to configure the AS so that it can act as an SSL service and an SSL client. So far, I have
managed to:
create a keystore containing a self-signed client entry for localhost
| cd $JBOSS_HOME
| keytool -genkey -keystore server/default/conf/wsse.keystore -storepass jbossws -keyalg
RSA -keysize 1024 -validity 1000 -alias localhost -dname "CN=localhost"
|
export a self-signed certificate for localhost
| keytool -export -keystore server/default/conf/wsse.keystore -storepass jbossws -alias
localhost -file server/default/conf/localhost.cer
|
create a truststore and import the localhost certificate
| keytool -import -keystore server/default/conf/wsse.truststore -storepass jbossws
-trustcacerts -alias localhost -file server/default/conf/localhost.cer
|
enable the secure port in JBossWeb (file
$JBOSS_HOME/server/default/deploy/jbossweb.sar/server.xml), telling it to use my keystore
and truststore
| <Connector protocol="HTTP/1.1" SSLEnabled="true"
| port="8443" address="${jboss.bind.address}"
| scheme="https" secure="true"
clientAuth="false"
| truststoreFile="${jboss.server.home.dir}/conf/wsse.truststore"
| truststorePass="jbossws"
| keystoreFile="${jboss.server.home.dir}/conf/wsse.keystore"
| keystorePass="jbossws"
| sslProtocol = "TLS" />
|
So, for exanple, with this setup I can access the JMX console via
https://localhost:8443/jmx-console. This works if
i) I enter the JMX console URL. and accept the certificate returned by the server when
prompted by the browser
or
ii) I install the contents of localhost.cer into the browser using the
Edit\Preferences\Encryption\ViewCertificates\Import dialogue chain and then enter the JMX
console URL.
Similarly, by installing/accepting this certificate I can use
https://localhost:8443/xts-demo to access the client GUI used to drive the test program
which starts the transaction. The problem happens when my client tries to establish an
HTTPS connection to the Activation Service.
The client obtains a JaxWS client proxy, sets the endpoint address to
"https://localhost:8443/ws-c11/ActivationService" and then invokes one of the
proxy's WebMethods. I assumed that the JaxWS/HTTPS layer on the XTS service side would
use the localhost certificate in the keystore to respond to the initial connect and that
the JaxWS/HTTPS layer on the XTS client side would accept this response because of
localhost entry in the truststore. What I actually get is an error from HTTPCientInvoker
followed by an exception from the SOAP stack
| 10:59:55,032 ERROR [HTTPClientInvoker] Error creating SSL Socket Factory for client
invoker: Error initializing socket factory SSL context: Can not find truststore url.
| 10:59:55,213 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
| java.io.IOException: Could not transmit message
| at
org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:264)
| at
org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:71)
| at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:340)
| at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:291)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:170)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150)
| at $Proxy205.createCoordinationContextOperation(Unknown Source)
| at
com.arjuna.webservices11.wscoor.client.ActivationCoordinatorClient.sendCreateCoordination(ActivationCoordinatorClient.java:86)
| at
com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:76)
| at
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:195)
| at
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:78)
| at
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:68)
| at
com.jboss.jbosstm.xts.demo.client.BasicClient.testAtomicTransaction(BasicClient.java:456)
| at com.jboss.jbosstm.xts.demo.client.BasicClient.doGet(BasicClient.java:408)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
| at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
| at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
| at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
| at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
| at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client
invoker after 1 attempt(s)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:246)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:158)
| at
org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:160)
| at org.jboss.remoting.Client.invoke(Client.java:1708)
| at org.jboss.remoting.Client.invoke(Client.java:612)
| at
org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:242)
| ... 35 more
| Caused by: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
| at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)
| at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
| at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
| at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848)
| at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
| at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
| at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
| at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
| at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
| at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)
| at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
| at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
| at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:857)
| at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
| at
org.jboss.remoting.util.SecurityUtility.getOutputStream(SecurityUtility.java:1514)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:331)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:228)
| ... 40 more
| Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
| at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221)
| at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145)
| at sun.security.validator.Validator.validate(Validator.java:203)
| at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172)
| at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
| at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:841)
| ... 54 more
| Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
| at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236)
| at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194)
| at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216)
| ... 59 more
|
I investigated this a little bit in the debugger and found that the HTTPClientInvoker
error derives from SSLSocketBuilder. It appears that it expects to validate the
(Activation Service) server certificate but has a null pointer for the keystore and the
truststore. This means it cannot establish a socket factory fro use when trying to make
the connection.
Is something wrong in my jbossweb or keystore/truststore configuration? Is there something
else I need to configure to get the remoting layer to use the keystore/truststore
specified in the jbosweb.sar/server.xml?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206952#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...