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...