<div dir="ltr">Hello,<div><br></div><div>I'm having an issue when configuring a HTTPS listener for Undertow via the JBOSS standalone.xml method.</div><div><br></div><div>(Wildfly 8.0.0.CR1).</div><div><br></div><div>I get the following ecception on startup:</div>
<div><div>2014-01-16 16:00:34,521 ERROR [org.jboss.msc.service.fail](MSC service thread 1-9) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service</div>
<div><span class="" style="white-space:pre"> </span>at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)</div><div><span class="" style="white-space:pre"> </span>at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)</div>
<div><span class="" style="white-space:pre"> </span>at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)</div><div><span class="" style="white-space:pre"> </span>at java.lang.Thread.run(Thread.java:724)</div>
<div>Caused by: java.lang.ClassCastException: Not a sequence</div><div><span class="" style="white-space:pre"> </span>at org.xnio.SequenceOption.cast(SequenceOption.java:57)</div><div><span class="" style="white-space:pre"> </span>at org.xnio.SequenceOption.cast(SequenceOption.java:31)</div>
<div><span class="" style="white-space:pre"> </span>at org.xnio.OptionMap.get(OptionMap.java:64)</div><div><span class="" style="white-space:pre"> </span>at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)</div><div><span class="" style="white-space:pre"> </span>at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)</div>
<div><span class="" style="white-space:pre"> </span>at org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)</div><div><span class="" style="white-space:pre"> </span>at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)</div>
<div><span class="" style="white-space:pre"> </span>at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)</div><div><span class="" style="white-space:pre"> </span>at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)</div>
<div><span class="" style="white-space:pre"> </span>... 3 more</div></div><div><br></div><div>My JBOSS Undertow configuration looks like this:</div><div><div><subsystem xmlns="urn:jboss:domain:undertow:1.0"></div>
<div> <span class="" style="white-space:pre"> </span><!-- SAA: for reference, there is not currently a default web xml in which we can globally disable unwanted HTTP methods.</div><div><span class="" style="white-space:pre"> </span>We have to expect the reverse proxy web server to restrict them.</div>
<div><span class="" style="white-space:pre"> </span>Nevertheless, Any Web Application can specifically disable them until JBoss start to provide a mechanism in here</div><div><span class="" style="white-space:pre"> </span>--> </div>
<div> <buffer-caches></div><div> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/></div><div> </buffer-caches></div>
<div> <server name="default-server"></div><div> <span class="" style="white-space:pre"> </span><!-- SAA: for reference, in ajp the Servlet/JSP Request URL is formed from the host and port of the client; browser or proxy.</div>
<div><span class="" style="white-space:pre"> </span>Web applications trying to use these values expecting them to be the local server and port would then be mistaken.</div><div><span class="" style="white-space:pre"> </span>As a workaround, we expect the reverse proxy web server to modify the Host Request Header to be equal to ths server's fully qualified host name and respective port, this will then mimmick the </div>
<div><span class="" style="white-space:pre"> </span>incoming requests to the http and https connectors.</div><div><span class="" style="white-space:pre"> </span>One example where this is crucial is REIMS Central Authentication Server as these details must match up against the domain advertised cas server url with highest priority </div>
<div><span class="" style="white-space:pre"> </span>--></div><div> <ajp-listener name="ajp" socket-binding="ajp"/></div><div> <http-listener name="http" socket-binding="http"/></div>
<div> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV" /></div>
<div> <host name="default-host" alias="localhost"></div><div> <location name="/" handler="welcome-content"/></div><div> <access-log directory="${jboss.server.base.dir}/log" prefix="localhost_access_log."/></div>
<div> </host></div><div> </server></div><div> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only"></div>
<div> <jsp-config x-powered-by="false"/></div><div> <persistent-sessions/></div><div> </servlet-container></div><div> <handlers></div><div>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/></div><div> </handlers></div><div> </subsystem></div>
</div><div><br></div><div>By process of elimination, I've found that removing the "enabled-cipher-suites" attribute makes the problem go away, so obviously this is the culprit.</div><div><br></div><div>The value I'm using for this attribute has simply been copied from our jboss-web configuration, previously "cipher-suite".</div>
<div><br></div><div>Am I using the attribute wrong, or is this a bug?</div><div><br></div><div>Any help greatly appreciated.</div><div><br></div><div>Cheers, Andy.</div></div>