Unless I'm doing something wrong, the method io.undertow.Undertow.Builder.addHttpsListener(int, String, KeyManager[], TrustManager[]) ignores the supplied KeyManager and TrustManager parameters. All TLS connections will fail the handshake due to Undertow being unable to negotiate a suitable cipher.

Debugging showed that Undertow ended up using Java's default SSLContext, which obviously don't have my key pair, so Java can't find an algorithm with a key.

I've traced the issue along the following path:
io.undertow.Undertow.Builder.addHttpsListener(int, String, KeyManager[], TrustManager[])
-> io.undertow.Undertow.start()
-> xnioSsl = new UndertowXnioSsl(xnio, OptionMap.create(Options.USE_DIRECT_BUFFERS, true), JsseSslUtils.createSSLContext(listener.keyManagers, listener.trustManagers, new SecureRandom(), OptionMap.create(Options.USE_DIRECT_BUFFERS, true)));
-> org.xnio.ssl.JsseSslUtils.createSSLContext(KeyManager[], TrustManager[], SecureRandom, OptionMap)

createSSLContext is being called with an OptionMap that does not contain Options.SSL_PROTOCOL, which in turn causes JsseSslUtils.createSSLContext to return SSLContext.getDefault(). At this point the user provided KeyManager[] and TrustManager[] are being lost.

Using the SSL-context version of addHttpsListener works as expected.