JBossDeveloper

The JVM properties should work as well. I didn't use them, because i try to call the server with different SSLContexts from the same standalone app. The only limitation is that I can't use different contexts in parallel, e.g. with multiple threads. So, when the JVM properties don't work it could be that my code don't work either.

The easiest way would be when the server uses an official SSL certificate. Then the client shouldn't need any additional configuration, but the certificate costs money. The next step is to use a self signed certificate on the server. Then you need the above mentioned truststore. I setup in addition a client certificate and use this for authentication to the server, but I think for your example the version with only a truststore fits better. So here is my code, I had to rewrite it a little bit, but I hope that  the general idea is visible:

TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());

// inS is an InputStream, from classloader or the filesystem to the keystore file, The ksPwd is the password for the truststore

// The SSL system uses only keystores. A keystore which contains only trusted certificates is used as truststore

trustStore.load(inS, ksPwd);

tmf.init(trustStore);

TrustManager[] tmArr = tmf.getTrustManagers();

SSLContext sslCtx = SSLContext.getInstance("TLS");

sslCtx.init(null, tmArr, null);

SSLContext.setDefault(sslCtx);

I hope that helps.

Sorry, I forgot to mention here, that thanks to Jaikiran, the issue is solved and available in the current WildFly from git.

I can configure the service consumer or client side and now the SSL connection works. At the moment the service provider or server side is not configurable. In class org.wildfly.extension.undertow.HttpsListenerService.startListening the OptionMap is hardcoded. Would it be a good idea to make this configurable, too? It is not necessary at the moment, but may be it can be used in future to start a connection without SSL and switch it on later. May be that this makes it possible to call a server with and without SSL. But this is only an idea and it may be nonsense . I don't know if this additional handling of encrypted connections is really needed and it may be possible to get this by configuring other parts of WildFly.

jaikiran pai schrieb:

 

Please file a enhancement JIRA for this in WFLY project and Undertow component. I am not sure if this was intentionally left out and if yes, the JIRA will be closed with an explanation.

Done with [#WFLY-2018] Configuring HttpsListenerServices xnio OptionMap - JBoss Issue Tracker.

By the way sorry for marking my post about the solved issue as "right answer". I don't know how I did this and removed it. I really don't wanted to get the points for pointing to the JIRA issue.