9 Replies Latest reply on Feb 10, 2009 3:55 AM by Ron Sigal

    Problem using JaxWS over HTTPS connection from within a depl

    Andrew Dinn Master

      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?




        • 1. Re: Problem using JaxWS over HTTPS connection from within a
          Andrew Dinn Master

          Ok, I resolved the SSLSocketBuilder error by adding

          -Djavax.net.ssl.trustStore=$JBOSS_HOME/server/default/conf/wsse.truststore -Djavax.net.ssl.trustStorePassword=jbossws -Djavax.net.ssl.keyStore=$JBOSS_HOME/server/default/conf/wsse.keystore -Djavax.net.ssl.keyStorePassword=jbossws
          


          to JAVA_OPTS. I am now getting a different which is actually more baffling.

          13:56:38,256 INFO [STDOUT] CLIENT: obtaining userTransaction...
          13:56:38,257 INFO [STDOUT] CLIENT: starting the transaction...
          13:56:38,949 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: java.io.IOException: HTTPS hostname wrong: should be <127.0.0.1>
           at sun.net.www.protocol.https.HttpsClient.checkURLSpoofing(HttpsClient.java:490)
           at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:415)
           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
          


          So, I noticed the fairly generous hint provided by the error message "HTTPS hostname wrong: should be <127.0.0.1>".

          I modified my keystore and truststore to include certificates with -alias 127.0.0.1 -dname "CN=127.0.0.1". I also modified my Activation Service proxy to use address "https:127.0.0.1:8443/ws-c11/ActrivationService". I checked and this was the address passed into the remoting layer. No joy.

          As a last ditch measure I tried booting JBossAS using -b 127.0.0.1. Still no joy.

          Any ideas?

          • 2. Re: Problem using JaxWS over HTTPS connection from within a
            Ron Sigal Master

            Hi Andrew,

            Well, here's a paragraph from the class javadoc for sun.net.www.protocol.https.HttpsClient:

             * <LI>It does basic server authentication, to protect
             * against "URL spoofing" attacks. This involves deciding
             * whether the X.509 certificate chain identifying the server
             * is trusted, and verifying that the name of the server is
             * found in the certificate. (The application may enable an
             * anonymous SSL cipher suite, and such checks are not done
             * for anonymous ciphers.)
            


            and here's the code for sun.net.www.protocol.https.HttpsClient.checkURLSpoofing() from openjdk:

             // Server identity checking is done according to RFC 2818: HTTP over TLS
             // Section 3.1 Server Identity
             private void checkURLSpoofing(HostnameVerifier hostnameVerifier)
             throws IOException
             {
             //
             // Get authenticated server name, if any
             //
             boolean done = false;
             String host = url.getHost();
            
             // if IPv6 strip off the "[]"
             if (host != null && host.startsWith("[") && host.endsWith("]")) {
             host = host.substring(1, host.length()-1);
             }
            
             Certificate[] peerCerts = null;
             try {
             HostnameChecker checker = HostnameChecker.getInstance(
             HostnameChecker.TYPE_TLS);
            
             Principal principal = getPeerPrincipal();
             if (principal instanceof KerberosPrincipal) {
             if (!checker.match(host, (KerberosPrincipal)principal)) {
             throw new SSLPeerUnverifiedException("Hostname checker" +
             " failed for Kerberos");
             }
             } else {
             // get the subject's certificate
             peerCerts = session.getPeerCertificates();
            
             X509Certificate peerCert;
             if (peerCerts[0] instanceof
             java.security.cert.X509Certificate) {
             peerCert = (java.security.cert.X509Certificate)peerCerts[0];
             } else {
             throw new SSLPeerUnverifiedException("");
             }
             checker.match(host, peerCert);
             }
            
             // if it doesn't throw an exception, we passed. Return.
             return;
            
             } catch (SSLPeerUnverifiedException e) {
            
             //
             // client explicitly changed default policy and enabled
             // anonymous ciphers; we can't check the standard policy
             //
             // ignore
             } catch (java.security.cert.CertificateException cpe) {
             // ignore
             }
            
             String cipher = session.getCipherSuite();
             if ((cipher != null) && (cipher.indexOf("_anon_") != -1)) {
             return;
             } else if ((hostnameVerifier != null) &&
             (hostnameVerifier.verify(host, session))) {
             return;
             }
            
             serverSocket.close();
             session.invalidate();
            
             throw new IOException("HTTPS hostname wrong: should be <"
             + url.getHost() + ">");
             }
            


            So it looks like the call to sun.security.util.HostnameChecker.match(host, peerCert) is failing, and there's no HostnameVerifier to save the day. The javadoc for HostnameVerifier.matchIP(), which is called when the host name looks like an IP address, says

             /**
             * Check if the certificate allows use of the given IP address.
             *
             * From RFC2818:
             * In some cases, the URI is specified as an IP address rather than a
             * hostname. In this case, the iPAddress subjectAltName must be present
             * in the certificate and must exactly match the IP in the URI.
             */
            


            On the other hand, when the host name doesn't look like an IP address, the method HostnameChecker.matchDNS() is called, the javadoc for which says

             /**
             * Check if the certificate allows use of the given DNS name.
             *
             * From RFC2818:
             * If a subjectAltName extension of type dNSName is present, that MUST
             * be used as the identity. Otherwise, the (most specific) Common Name
             * field in the Subject field of the certificate MUST be used. Although
             * the use of the Common Name is existing practice, it is deprecated and
             * Certification Authorities are encouraged to use the dNSName instead.
             *
             * Matching is performed using the matching rules specified by
             * [RFC2459]. If more than one identity of a given type is present in
             * the certificate (e.g., more than one dNSName name, a match in any one
             * of the set is considered acceptable.)
             */
            


            Well, here's a guess. If the host name looks like an IP address, the certificate must have that address in a subjAltNames extension. It looks like you can do that with openssl but not keytool. That might be one solution.

            Or, alternatively, try "localhost" instead of 127.0.0.1.

            Or, for a nasty workaround, you can tell HTTPSClientInvoker to use a HostnameVerifier that accepts any name. To do that, add the parameter "org.jboss.security.ignoreHttpsHost", set to "true", when you set up the Remoting client. I'm not sure how you're doing that, but if you're creating an org.jboss.remoting.Client, you can pass a configuration map to the constructor.

            Making it up as I go,
            Ron

            • 3. Re: Problem using JaxWS over HTTPS connection from within a
              Andrew Dinn Master

              Thanks very much for the explanation Ron. After a lot of searching yesterday I found (via google :-) your ''nasty workaround" in the JBossWS Wiki and managed to get HTTPS to work just before I finished work. Sorry for not posting my results earlier.

              I had previously tried your other suggestion and used localhost as the key/truststore alias and CN name and as the host in the URL. Interestingly, this still gave the error "HTTPS hostname wrong: should be <127.0.0.1>". I don't really understand why it's printing the IP address rather than hostname in this case.

              I am only doing this to test the XTS comms layer so I think I am going to stop here for now. I'm sure I'll have to come back to it when we start trying to do interop testing with Microsoft (or when a community user tries it). Thanks for the help.

              • 4. Re: Problem using JaxWS over HTTPS connection from within a
                Andrew Dinn Master

                Ron,

                Just for the record I tracked down the source of the problem with the server host name check and managed to get the https exchange to work without having to specify org.jboss.security.ignoreHttpsHost=true. It turns out that my (vanilla) /etc/hosts file contained the line

                127.0.0.1 localhost.localdomain localhost

                I think this was messing up the server name verification because the source IP address for the server response (127.0.0.1) was resolving to localhost.localdomain while the name supplied in the ticket was localhost.

                Anyway, so much for the theory. Once I swapped the alias entries around in /etc/hosts to place localhost first I was able to drop the setting org.jboss.security.ignoreHttpsHost=true and it all worked ok. Thanks again for your help.

                • 5. Re: Problem using JaxWS over HTTPS connection from within a
                  Ron Sigal Master

                  Hey Andrew,

                  I'm relieved to know there's a solution. Thanks.

                  Anyway, I'm happy to appear to seem useful. :)

                  [And the name of the song is called ... ]

                  -Ron

                  • 6. Re: Problem using JaxWS over HTTPS connection from within a
                    Andrew Dinn Master

                     


                    Anyway, I'm happy to appear to seem useful. :)

                    [And the name of the song is called ... ]


                    Uh, . . . is it No Feelings by the Sex Pistols?

                    • 7. Re: Problem using JaxWS over HTTPS connection from within a
                      Ron Sigal Master

                      Oh you kids. :)

                      In olden times, when you could get into CBGB's for free in the afternoon and stay for the music, I saw Talking Heads, who opened for The Ramones. This is before anyone ever heard of them. Perceptive as I am, I decided that they were both lame and would never amount to anything.

                      Anyway, I was just hanging around to meet Patti Smith. Never happened.

                      But I've met Gavin King. :)

                      • 8. Re: Problem using JaxWS over HTTPS connection from within a
                        Andrew Dinn Master

                        Ron,

                        Just add some V U and a dash of Marquee Moon and you have the royal flush of teenage fandom from my most formative years.

                        How do you spell KUDOS? GIve me an R . . . Give me an O . . . Give me an N . . .

                        • 9. Re: Problem using JaxWS over HTTPS connection from within a
                          Ron Sigal Master

                          :)

                          Hey hey, my my
                          Rock and roll can never die
                          There's more to the picture, than meets the eye
                          Hey hey, my my