Support PEM keystores

[hgeraldino]

Is your feature request related to a problem? Please describe.

When enabling SSL in the rabbitmq-java-client library, it is possible to configure the key store type (ssl.key.store.type) to use either JKS or PKCS12 formats. The JKS format is barely used outside of Java, whereas PKCS12 is more common (and is the default KeyStore format since JDK9).

Describe the solution you'd like

I think it is a good idea to add support for PEM files (in addition to the existing JKS/PKCS12) for key and trust stores. PEM files are widely used across the industry, and extending the library to support them will make it easier to integrate with third party providers that use PEM, without asking users to manually import these certificates into an existing Java KeyStore file.

Describe alternatives you've considered

No response

Additional context

I'm happy to work on implementing this, if we agree it's a good idea.

[lukebakken]

So, basically, import what TlsTestUtils.java does into this library?

This seems reasonable to me, I suppose, especially since all of the RabbitMQ docs use X509 certs in .pem files.

Just FYI, for generating certs the tls-gen project should be used.

@acogoluegnes will have comments to add here I'm sure 😸

[michaelklishin]

@hgeraldino first class PEM support in JDK is a very recent development that has first shipped in JDK 25 as a "preview".

This client still supports JDK 8 and that will remain for as long as maintained Spring AMQP series do the same thing.

If there is a way to support .pem files and retain JDK 8 support, our team would be all for it but it's on those who want to use that format to investigate.

[michaelklishin]

And yeah, pointing at this project or that is not going to move anything forward, so I have removed that part of the description. This project, together with a majority of the open source JVM-based ecosystem, cannot just begin requiring JDK 25 or 26.

We are a very small team and we have certain backwards compatibility obligations, however ridiculous JDK 8 support may seem to some today, and pointing out at other projects will not change that.

So someone has to step up and contribute PEM support, and we should be confident enough in this feature to agree to then maintain it forever (the original contributor likely won't, we have a lot of experience with community contributions).

@hgeraldino would you be interested in investigating what our PEM support options are given the JDK 8 support constraint?

[lukebakken]

Well, the pom.xml file specifies JDK 8 as the minimum version, so you'd think all the code in this project is compatible.

I just confirmed that the code in TlsTestUtils compiles using JDK 8 and CI is totally green, so I think @hgeraldino could easily use the code in that class to add PEM file support. I wouldn't use any different APIs, of course. I'm pretty sure everything that is needed is in that file.

[acogoluegnes]

@hgeraldino What do you want to achieve exactly? Can you provide some mock test code?

As @lukebakken mentioned, the test suite uses the standard JDK TLS utilities to import certificates from PEM files and this works on Java 8.

[hgeraldino]

Hi,

Thanks for taking the time to review this issue, I'm impressed (and thrilled) on how quickly feedback was provided. I'm definitely not suggesting on adopting JEP 470, but to write our own small utility functions to parse/load certificates from PEM files.

It is very common for Certificate Authorities to distribute certificates in PEM format. I'm happy to work on implementing this, and to get an idea on how this can be achieved, here are a couple of (Apache) examples:

• ZooKeeper's PemReader
• Kafka's PemStore

These will compile on JDK8, no problem. I think it's a good idea to provide an implementation (either porting code from TlsTestUtils, or writing our own) rather than introducing some 3rd party dependencies.

If we all agree that this is a desirable feature, I'll work on a PR in a couple weeks.

[michaelklishin]

@hgeraldino IIRC you have to sign our CLA (we will send you a tailored version that your employer has approved) but other than that, feel free to submit a PR that would make it easier to load certificates and keys in the PEM format.

RabbitMQ itself and pretty much every client except for Java, .NET (and Objective-C, SWIFT) exclusively use the PEM format, so you don't have to convince anyone in its usefulness.

We can use an existing ASL2-based implementation or use our own TlsTestUtils as a foundation and polish it. I suspect many on our team would prefer the latter option but I personally do not have a strong opinion.