How is TLS certificate renewal done in the wildfly source code?

[Melvin Sam]

Hi everyone,

I need to be able to renew certificates without having to restart my server. On my server, TLS is used in the undertow, remoting, and JMS subsystems. I found this link online:

https://wildfly-security.github.io/wildfly-elytron/blog/obtaining-certificates-from-lets-encrypt-using-the-wildfly-cli/#using-a-cli-script-to-automate-certificate-renewal

From trying it myself, I found all I need was to run these 2 cli commands:

-  /subsystem=elytron/key-store=MY_KS:load()
-  /subsystem=elytron/key-manager=MY_KM:init()

This works when I can configure my subsystems to reference the elytron ssl context (which I was able to do for undertow and remoting), however, my JMS schema is version 13 (Im using JBOSS EAP 7.4 and we cannot upgrade to 8 any time soon). This version of JMS doesnt have the ssl context property on the xml schema (unlike the latest which is 15, which does have the sslcontext xml attribute), and as such, when I renew certificates, only the undertow and remoting subsystems have the updated certificates, while JMS fails because its still using the previous certificate.

I wonder if updating the JMS subsystem in isolation would be enough to fix this issue, but I would like to have some more information before I try that. How do these 2 cli commands update the sslcontext? Is it like an event that gets propagated to the other subsystems? Is there only one instance of the sslcontext that is used by all these subsystems? My idea is that perhaps I can simply update a small portion of JMS to use the elytron sslcontext directly even if not accessible from the schema, instead of updating the JMS in itself while the other subsystems remain in the older versions.

Any pointers to classes on the wildfly/jboss source code to look at, or any other opinions would be appreciated.