Cannot use JMS over HTTPS port in WildFly

[sam.jones]

I want to post this question to get a definitive, bare minimum configuration that is supposed to work. I have been trying to get JMS to work using the https port, but I'm having no luck. I came across these threads: WildFly CR1 HornetQ over https: HQ119013: Timed out waiting to receive cluster topology and Re: Problem connecting to jms topic when using https. I also see that there is an outstanding bug that is related to my issue: [HORNETQ-1317] Error connecting with http-upgrade mechanism against https port on WildFly - JBoss Issue Tracker. However, I don't see the exact same error message. SSL is working in the browser when I go to my application's web root.

This is what I have added to the configuration.

<server xmlns="urn:jboss:domain:2.0">

     ...

    <management>

        <security-realms>

            ...

            <security-realm name="UndertowRealm">

                <server-identities>

                    <ssl>

                        <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="changeit" alias="server" key-password="changeit"/>

                    </ssl>

                </server-identities>

            </security-realm>

        </security-realms>

        ...

     </management>

    <profile>

         ...

        <subsystem xmlns="urn:jboss:domain:messaging:2.0">

            <hornetq-server>

                ...

                <connectors>

                    ...

                    <http-connector name="https-connector" socket-binding="https">

                        <param key="http-upgrade-endpoint" value="https-acceptor"/>

                        <param key="ssl-enabled" value="true"/>

                    </http-connector>

                </connectors>

                <acceptors>

                     ...

                    <http-acceptor name="https-acceptor" http-listener="https"/>

                </acceptors>

                <jms-connection-factories>

                    ...

                    <connection-factory name="SecureRemoteConnectionFactory">

                        <connectors>

                            <connector-ref connector-name="https-connector"/>

                        </connectors>

                        <entries>

                            <entry name="java:/SecureRemoteConnectionFactory"/>

                            <entry name="java:jboss/exported/jms/SecureRemoteConnectionFactory"/>

                        </entries>

                        <connection-ttl>-1</connection-ttl>

                        <reconnect-attempts>-1</reconnect-attempts>

                    </connection-factory>

                    ...

                </jms-connection-factories>

                ...

            </hornetq-server>

        </subsystem>

        ...

        <subsystem xmlns="urn:jboss:domain:undertow:1.0">

            ...

            <server name="default-server">

                ...

                <https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>

                ...

            </server>

            ...

        </subsystem>

         ...

     </profile>

     ...

</server>

My client-side code looks like the following:

Properties env = new Properties();

env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

env.put(Context.PROVIDER_URL, "http-remoting://localhost:8443");

env.put(Context.SECURITY_PRINCIPAL, "test");

env.put(Context.SECURITY_CREDENTIALS, "****");

InitialContext ic = new InitialContext(env);

TopicConnectionFactory factory = (TopicConnectionFactory) ic.lookup("jms/SecureRemoteConnectionFactory");

TopicConnection connection = cf.createTopicConnection("test", "****");

The program's command-line arguments include the following:

-Djavax.net.ssl.trustStore=C:\Path\to\truststore.jks

-Djavax.net.ssl.trustStorePassword=****

The client throws an error on the lookup line:

javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [http-remoting://localhost:8443 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)]

  at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244)

  at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)

  at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)

  at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)

  at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)

  at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)

  at javax.naming.InitialContext.lookup(InitialContext.java:411)

[gaohoward]

Hi I think at this point the problem is in Wildfly remoting jndi. You probably can post this to their forum too. To see if there is also problem with HornetQ, you can first use plain HTTP jndi to make JNDI lookup work, then run the test and see if there is more errors to occur.

[ataylor]

I think its [HORNETQ-1317] Error connecting with http-upgrade mechanism against https port on WildFly - JBoss Issue Tracker

[sam.jones]

I forgot to mention that I can use plain HTTP without any problem. I have been able to use the out-of-the-box RemoteConnectionFactory.

Configuration:

        <subsystem xmlns="urn:jboss:domain:messaging:2.0">

            <hornetq-server>

                <jms-connection-factories>

                    <connection-factory name="RemoteConnectionFactory">

                        <connectors>

                            <connector-ref connector-name="http-connector"/>

                        </connectors>

                        <entries>

                            <entry name="java:/RemoteConnectionFactory"/>

                            <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>

                        </entries>

                        <connection-ttl>-1</connection-ttl>

                        <reconnect-attempts>-1</reconnect-attempts>

                    </connection-factory>

                </jms-connection-factories>

            </hornetq-server>

        </subsystem>

Code:

    Properties env = new Properties();

    env.put(Context.INITIAL_CONTEXT_FACTORY, JndiConfiguration.INITIAL_CONTEXT_FACTORY);

    env.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");

    InitialContext ic = new InitialContext(env);

    TopicConnectionFactory factory = (TopicConnectionFactory) ic.lookup("jms/RemoteConnectionFactory");

[gaohoward]

HornetQ-1317 has been fixed long time ago. According to the log the fix is done in early February this year. So I believe this is a JNDI over SSL problem, not a jms over https problem.

Howard

[jmesnil]

@sam: the error you have is in the JNDI lookup before you use any JMS resources. This means that the issue is in the way you use SSL in WildFly.

@howard, HORNETQ-1317 has been fixed in hornetq master branch but there is no release with this fix. Once HornetQ releases a 2.4.2.Final, I'll upgrade it into WildFly and this should fix the issue

[sam.jones]

Any suggestions on how I can use it correctly? Is there anything wrong with my configuration or code?

[jaikiran]

env.put(Context.PROVIDER_URL, "http-remoting://localhost:8443");

That should be https-remoting and not http-remoting

[sam.jones]

When I change it to https-remoting, I get the following error:

javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [https-remoting://localhost:8443 (java.io.IOException: Invalid response code 200)]

  at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244)

  at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)

  at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)

  at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)

  at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)

  at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)

  at javax.naming.InitialContext.lookup(InitialContext.java:411)

[jaikiran]

Are you sure you are using the correct version of libraries on the client side (the ones that match the WildFly version against which you are running)?

[sam.jones]

I double checked to make sure, but yes, I am building the client using the jboss-client.jar that came with WildFly.

[gaohoward]

make sure your application can find your trust store "C:\Path\to\truststore.jks". If you have "\" you probably make sure you escaped it like "\\".

[crazycradd]

I have just tested this again in 8.2 and it still fails.

Here is the jms config
<connectors>
<http-connector name="http-connector" socket-binding="https">
<param key="http-upgrade-endpoint" value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput" socket-binding="https">
<param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default" name="http-acceptor"/>
<http-acceptor http-listener="default" name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
</acceptors>

Here is the undertow config
<http-listener max-parameters="10000" name="local" socket-binding="http"/>
<host alias="localhost" name="default-host">
<location handler="welcome-content" name="/wildfly"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
<https-listener max-parameters="10000" name="default" security-realm="ssl-realm" socket-binding="https"/> 

and here is the error message I get
[java] 18:07:29,580 DEBUG [JavassistTypeParameterMatcherGenerator] Generated: io.netty.util.internal._matchers_.i
o.netty.handler.codec.http.HttpObjectMatcher
[java] javax.jms.JMSException: Failed to create session factory
[java]  at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.jav
a:673)

[mayankmit2002]

Seems as if it is related to

[HORNETQ-1172] Provide Websocket-like HTTP upgrade protocol - JBoss Issue Tracker

[bwicks]

As of Wildfly 8.2.0.Final this has been resolved.  Below is an example of what it took for us to get remote JMS working over SSL.

Make sure client is using https-remoting://

Here is the final configuration setup.  The 'ssl-enabled' on the throughput connector was the final piece.

<server xmlns="urn:jboss:domain:2.2">

    <management>

       <security-realms>

            ...    

  <security-realm name="My_Secure_Realm">

  <authentication>

  <local default-user="$local" allowed-users="*" skip-group-loading="true" />

  <properties path="application-users.properties" relative-to="jboss.server.config.dir" />

  </authentication>

  <authorization>

  <properties path="application-roles.properties" relative-to="jboss.server.config.dir" />

  </authorization>

  <server-identities>

  <ssl>

  <keystore path="/path/to/keystore.jks" keystore-password="*******" />

  </ssl>

  </server-identities>

  </security-realm>

  </security-realms>

  ...

  </management>

  <subsystem xmlns="urn:jboss:domain:messaging:2.0">

  <hornetq-server>

  ...

  <connectors>

  <http-connector name="http-connector" socket-binding="https">

  <param key="http-upgrade-endpoint" value="http-acceptor" />

  <param key="ssl-enabled" value="true" />

  </http-connector>

  <http-connector name="http-connector-throughput" socket-binding="https">

  <param key="http-upgrade-endpoint" value="http-acceptor-throughput" />

  <param key="batch-delay" value="50" />

  <param key="ssl-enabled" value="true" />

  </http-connector>

  <in-vm-connector name="in-vm" server-id="0" />

  </connectors>

  <acceptors>

  <http-acceptor http-listener="default-ssl" name="http-acceptor" />

  <http-acceptor http-listener="default-ssl" name="http-acceptor-throughput">

  <param key="batch-delay" value="50" />

  <param key="direct-deliver" value="false" />

  </http-acceptor>

  <in-vm-acceptor name="in-vm" server-id="0" />

  </acceptors>

  ...

  </hornetq-server>

  </subsystem>

  <subsystem xmlns="urn:jboss:domain:remoting:2.0">

  <endpoint worker="default" />

  <http-connector name="http-remoting-connector" connector-ref="default-ssl" security-realm="My_Secure_Realm" />

  </subsystem>

  <subsystem xmlns="urn:jboss:domain:undertow:1.2">

  ...

  <server name="default-server">

  <https-listener max-post-size="104857600" name="default-ssl"

  socket-binding="https" security-realm="My_Secure_Realm" />

  <host name="default-host" alias="localhost">

  <location name="/" handler="welcome-content" />

  <filter-ref name="server-header" />

  <filter-ref name="x-powered-by-header" />

  </host>

  </server>

  ...

  </subsystem>

  <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

  ...

  <socket-binding name="https" port="${jboss.https.port:8443}" />

  ...

  </socket-binding-group>

</server>