ManagementContext should support sslContext injection

[jbonofre]

If an user wants to use SSL with JMX, the only option today is to configure via the command line (-Dcom.sun.management.jmxremote.port=xxxx -Dcom.sun.management.jmxremote.ssl=true).

This configuration doesn't use the sslContext meaning that the user might have to duplicate the SSL configuration two times:

• the sslContext in activemq.xml that can be used in transportConnector
• the same configuration via the command line (com.sun.management.jmxremote*)

It would be great to be able to inject the sslContext in the <managementContext/> to use an unique configuration.

Something like:

    <sslContext>
      <sslContext id="fooContext"
        keyStore="file:./path/broker2.ks" keyStorePassword="password"
        trustStore="file:./path/client2.ks" trustStorePassword="password"/>
    </sslContext>

    <managementContext>
        <managementContext createConnector="true" sslContext="#fooContext"/>
    </managementContext> 

[jeanouii]

Started already on this one, so I'll move it forward up to completion.

[anmol-saxena-14]

Hi @jeanouii ,

I was also looking into the same issue. After reviewing your PR and the original context of AMQ-9857, I believe we should also consider adding a broker-level SSL fallback into ManagementContext, as this aligns closely with the original intent of the issue.

From the issue context (AMQ-9857):

Today, users can define SSL once in activemq.xml (broker ) and reuse it for transport connectors. However, JMX requires a separate SSL setup (often via JVM com.sun.management.jmxremote.* arguments), which forces users to duplicate SSL configuration. The goal is to avoid configuring SSL twice and allow a single source of truth in broker configuration.

Suggested logic in BrokerService.startManagementContext():

If managementContext.getSslContext() == null and brokerService.getSslContext() != null, set management SSL from broker SSL.
Then start management context as usual.

To address, I have included additional logic in my PR:
#1710

Adding these changes:

• Will preserves existing explicit behaviour: if managementContext.sslContext is set, that value still wins.
• It removes duplication for the common case: users define broker SSL once, and JMX automatically inherits it.
• It aligns JMX behavior with transport connectors, which already benefit from broker-level SSL defaults.
• It directly addresses the issue’s main pain point: duplicate SSL config between transport and JMX.

cc: @jbonofre

[jbonofre]

Just for context, the rationale is also to consolidate the SSL configuration across transport connector and JMX layer (management context). Today, the two configurations are "isolated" from each other.

So, anything in this direction is a good idea.

@asaxena14 as you can see in the issue description, I mentioned:

    <sslContext>
      <sslContext id="fooContext"
        keyStore="file:./path/broker2.ks" keyStorePassword="password"
        trustStore="file:./path/client2.ks" trustStorePassword="password"/>
    </sslContext>

    <managementContext>
        <managementContext createConnector="true" sslContext="#fooContext"/>
    </managementContext> 

It looks very similar to what you propose (the syntax is slightly different, but I don't have a strong opinion on the syntax as soon as it's "user friendly").