The first command is security enable-ssl-http-server, in addition to defining new resources in the Elytron subsystem this takes the https listener from:

<https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>

To:

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

This has activated the use of an Elytron SSLContext but it has not enabled SSL, SSL was already enabled by the presence of the https-listener which was referencing a security-realm to obtain it's SSLContext.

The command security disable-ssl-http-server takes it back to the first form, however that has not disabled SSL it has just changed the source of the SSLContext to use for SSL.

The default configuration is being changed to something like:

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

This is the equivalent of the original configuration but now the initial SSLContext comes from the Elytron subsystem not a security realm. Trying to use the security enable-ssl-http-server command now fails with:

[standalone@localhost:9990 /] security enable-ssl-http-server --key-store-path=/home/darranl/Tasks/WFLY-15001/security-commands/localhost.keystore --key-store-password=keystore_password --key-store-type=JCEKS
*SSL is already enabled for default-server*

At this point it is as enabled as it has always been.

Finally the security disable-ssl-http-server command will still operate by reverting to the ApplicationRealm security realm - but these will no longer be available - the https-listener resource can also not be left with ssl-context undefined as it is a required attribute.

Maybe enable-ssl-https-security will need to also cope with the https-listener not even being defined and dynamically define it? It probably should be tolerant to always set the ssl-context even if one was already set, maybe with a flag to override and treat applicationSSC as a special case although the name may change.

Regarding disable-ssl-https-security the only way to disable is to remove the https-listener entirely, at the moment assumptions are being made about resources that may just not exist.

I have marked this as Critical as the default configuration is evolving but the CLI commands are not flexible enough so will require further rework.