See: http://lists.jboss.org/pipermail/undertow-dev/2014-January/000670.html

I'm having an issue when configuring a HTTPS listener for Undertow via the JBOSS standalone.xml method.

I get the following exception 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">
<buffer-caches>
<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
</buffer-caches>
<server name="default-server">
<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 it appears this is the culprit.

The value I'm using for this attribute has simply been copied from our jboss-web configuration, previously "cipher-suite".