Add PEM Certificate Support for Jolokia TLS Configuration

[cezarpaulo16]

Story Description:

Currently, ecChronos supports TLS configuration for CQL connections using both keystore-based and PEM certificate-based authentication in the security.yml file. The CQL TLS configuration allows users to specify:
• certificate: - Path to PEM certificate file
• certificate_private_key: - Path to PEM private key file
• trust_certificate: - Path to PEM trust certificate file

However, there is no Jolokia configuration to support PEM certificate-based TLS configuration.

Current State:
Jolokia TLS configuration lacks PEM certificate support, while CQL already provides this functionality.

Proposed Enhancement:
Add support for PEM certificate-based TLS configuration to Jolokia connections

Acceptance Criteria:

[AC1]: Jolokia configuration supports PEM certificate parameters: certificate, certificate_private_key, and trust_certificate.

[AC2]: When PEM certificate parameters are provided for Jolokia, the system successfully establishes TLS connections using those certificates.

Definition of Done:
• Jolokia TLS configuration updated to support PEM certificate parameters
• Certificate handling implementation for Jolokia connections

Notes:

[VictorCavichioli]

Related with #652

[grgrzybek]

Interesting!
May I kindly ask about "Jolokia connections" - how do you configure these? Are you using J4pClientBuilder as in https://jolokia.org/reference/html/manual/clients.html#client-client ?

But another reason I started the refactoring are these issues:

As mentioned under jolokia/jolokia#911, these issues change the way current J4pClient is used. I've also took the opportunity to rename it to JolokiaClient (not sure anyone remembers that J4p is JMX for Perl :)

• Consider using JDK own HTTP client jolokia/jolokia#565
• Improve Jolokia serialization and use it in jolokia-client-java jolokia/jolokia#888
• Issues with flight recordings over JMX adapter jolokia/jolokia#613

If you could point me to your code fragment, where you configure and use J4pClient, I could ensure the best compatibility and least problematic update of the client (so you can easily specify various SSL configuration - both for the SSLContext (keystores) and SSLParameters (algs, ciphers)).

[VictorCavichioli]

Hi @grgrzybek,

Today jolokia connections are created through DistributedJmxBuilder.java, as this "agent" feature must maintain compatibility with the old way of creating jmx connection (the RMI one) we are using the default client that JolokiaJmxConnectionProvider creates, so in my perspective as a "jolokia customer" would be really good for us to configure the J4pClient and pass to JolokiaJmxConnectionProvider as a parameter or a property of the env object, I guess that would be easier to all the customers because it would allow the client to work in different configurations and you would not need to treat each case internally in jolokia-adapter for example.

You might be asking yourself "Why they are not using J4pClient directly" and of course this is a good question and the answer is because we need to continue treating the connection as a JMXConnection to maintain the compatibility with the old way, as they will coexist, creating different proxies for each one woul involve a lot of refactoring and changes in the architecture, in case you want to see, this is our proxy that communicates with Cassandra today DistributedJmxProxyFactoryImpl.java

Thank you for your interest. We are fully open to your feedback as a Jolokia expert. Finally, a while ago we talked about addNotificationListener support in the Jolokia-adapter. In our service, I implemented an implementation that helped us manage it automatically. If you'd like to include it in the adapter JolokiaNotificationController.java