https-listener in standalone.xml

[Niko W]

Hi,

I am currently working on the implementation of SSL for the HTTPS-Listener in Wildfly 26.0.1

The documentation shows those parameters (same as I know from Wildfly 10.x)

https://docs.wildfly.org/26/Admin_Guide.html#https-listener

<https-listener name="default" socket-binding="https" security-realm="ssl-realm" />

but in standalone.xml it looks like this...

<https-listener name="https" socket-binding="https" ssl-context="applicationSSC" enable-http2="true"/>

The parameter ssl-context is not really documented and in fact not in context of https-listener.

So what to do there?

Add the parameter security-realm="ssl-realm" or change ssl-context="applicationSSC" against security-realm="ssl-realm"?

Any clues?

[Darran Lofthouse]

That is a bug in the documentation that needs cleaning up, security-realm attributed can not be used anymore.

The ssl-context reference should be used and that references the resource in the Elytron subsystem.

[Niko W]

Currently I am working on the steps that are documented here after I noticed that the "old way" with security realm does not work any longer...
https://docs.jboss.org/author/display/WFLY/Using%20the%20Elytron%20Subsystem.html

Enable One-way SSL/TLS for Applications

• Configure a key-store in WildFly
• Configure a key-manager in that references your key-store
• Configure a server-ssl-context in that references your key-manager
• Check and see if the https-listener is configured to use a legacy security realm for its SSL configuration

It seems to work this way. After you implemented those steps via jboss-cli, you can observe the changes made to standalone.xml

Only problem at this point, is that the created xml does not contain a place to configure the alias that should be used from the configured jks...

Working on that...

[Darran Lofthouse]

The filtering of the aliases from the KeyStore has been moved to the KeyStore definition:

https://docs.wildfly.org/26/wildscribe/subsystem/elytron/key-store/index.html

There are some use cases where more than one is desirable such as different entries being usable with different cipher suites, by filtering at the keystore level it also allows the KeyManager to influence the offered cipher suites based on the entrie(s) in the KeyStore.