5:47 p.m.
Hello,
I'm having an issue when configuring a HTTPS listener for Undertow via the
JBOSS standalone.xml method.
(Wildfly 8.0.0.CR1).
I get the following ecception on startup:
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
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.ClassCastException: Not a sequence
at org.xnio.SequenceOption.cast(SequenceOption.java:57)
at org.xnio.SequenceOption.cast(SequenceOption.java:31)
at org.xnio.OptionMap.get(OptionMap.java:64)
at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)
at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)
at
org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)
at
org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
My JBOSS Undertow configuration looks like this:
<subsystem xmlns="urn:jboss:domain:undertow:1.0">
<!-- SAA: for reference, there is not currently a default web xml
in which we can globally disable unwanted HTTP methods.
We have to expect the reverse proxy web server to restrict them.
Nevertheless, Any Web Application can specifically disable them until JBoss
start to provide a mechanism in here
-->
<buffer-caches>
<buffer-cache name="default" buffer-size="1024"
buffers-per-region="1024" max-regions="10"/>
</buffer-caches>
<server name="default-server">
<!-- SAA: for reference, in ajp the Servlet/JSP Request URL is
formed from the host and port of the client; browser or proxy.
Web applications trying to use these values expecting them to be the local
server and port would then be mistaken.
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
incoming requests to the http and https connectors.
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
-->
<ajp-listener name="ajp" socket-binding="ajp"/>
<http-listener name="http"
socket-binding="http"/>
<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"
/>
<host name="default-host" alias="localhost">
<location name="/"
handler="welcome-content"/>
<access-log directory="${jboss.server.base.dir}/log"
prefix="localhost_access_log."/>
</host>
</server>
<servlet-container name="default"
default-buffer-cache="default" stack-trace-on-error="local-only">
<jsp-config x-powered-by="false"/>
<persistent-sessions/>
</servlet-container>
<handlers>
<file name="welcome-content"
path="${jboss.home.dir}/welcome-content"
directory-listing="true"/>
</handlers>
</subsystem>
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.
The value I'm using for this attribute has simply been copied from our
jboss-web configuration, previously "cipher-suite".
Am I using the attribute wrong, or is this a bug?
Any help greatly appreciated.
Cheers, Andy.