Why is listener-specific keystore not used for subsequent follow-up requests?

Technical Discussion
1

I have configure different keystores for listener-1 and listener-2.
When performing an https request on these listeners, a JAX-RS resource is triggered.
That JAX-RS resource in turn instantiates a JAX-RS client to perform subsequent https requests to a third party resource.
I noticed that the keystores defined at listener-1 and listener-2 are NOT forwarded to that JAX-RS client, but instead the DEFAULT keystore is used.
This is a bit counterintuitive.
Is there an option to make Payara forward the specific keystore of the active listener to the JAX-RS client created tempoarily when answering the request on that listener?

3

Hi,

I think this is what you need: JAX-RS extension :: Payara Community Documentation - a JAX-RS extension added in Payara Server 5.2021.9, which allows to specify an alias in the keystore of the certificate you want to use with the JAX-RS request. It’s an extensions, so you need to add it into your application and it should in theory work on older Payara Server versions. It doesn’t support using the very same certificate used for the listener and expects you to specify the alias for each request. But you can easily modify the extension source code (here: ecosystem-rest-ssl-configuration/ClientBuilderExtension.java at 10940ed93d4181d74f98c3b73a1cf5c06cd52007 · payara/ecosystem-rest-ssl-configuration · GitHub) and build your own custom version to support reading the alias from a system property or from application’s configuration (e.g. from MP Config, where Payara Server allows specifying config per application). Then you would specify the alias globally per application and you won’t need to specify it with each request.

Ondro

4

When authoring your answer, did you actually know that I am a co-author of the JAX-RS specification? :wink:

1 Like
5

Thanks Ondro, that is a great extension, but I really think it would be better if Payara would have an option at the listener that simply passes the listeners SSL config to the client. Maybe we need to extend the JAX-RS specification to clearly indicate that and / or to allow injecting a JAX-RS Client etc. WDYT?