Add SSL bundle support to WebClient auto-configuration

[62mkv]

As suggested by @wilkinsona in #6493, I raise an issue to ask to add a simplified way to add "trust store" details when it's only needed for connecting to outgoing services, that use "exotic" certificates. It can be easily done with the help of system properties, but it's not always possible to set up (for example, with Spring Boot war built via Java S2I and running on OpenShift - JAVA_OPTS and CATALINA_OPTS are just ignored)

Our application uses Spring 5 WebClient for connectivity

I would want to have a way to provide a path and optionally password to a trustStore via environment variables, much as one can do with SERVER_SSL_TRUST_STORE but unfortunately it does not work without ALSO providing key store details, which is something we don't want as the application works behind OpenShift Load-Balancer over HTTP, thus we don't set up SSL server at all

[wilkinsona]

Thanks for raising an issue, @62mkv.

I think this might be one where you have to perform at least some of the configuration yourself. I think it's quite likely that an application may have multiple WebClient instances and want each to have different certificates in its truststore or no custom truststore at all. It's due to this sort of difference in WebClient configuration that we configure a WebClient.Builder bean rather than a WebClient bean.

We may still be able to do something here to make things easier for you. For example, it might be harder than necessary to use the WebClient.Builder to create a WebClient with a custom truststore. That would be something that we could improve in Spring Boot or Spring Framework. To help us look at possible improvements, could you please describe in a bit more detail how you're configuring your WebClient to meet your needs at the moment?

We could also consider offering something that applies to every WebClient that can be opted in to. If you're happy with the same truststore being used across instances then you could use it. If you're not, you could configure things yourself (with some possible improvements on our side to make it easier) on a per-client basis.

[62mkv]

Yes, we use a @Configuration to configure a WebClient.Builder which is then injected into a service that actually consumes the external API by wrapping an OpenApi-generated client.

Ideally, we would want to have something like described here: #6493 (comment) but that's so much of the code, it really feels as if that should be easier for an end-user to configure. I could, say, have a configuration key, specifying a path to a folder, (under resources, maybe), that could keep several certificates, which I want to have added to a Trusted Storage alongside the default ones.

[62mkv]

I've provided a quick note-to-self here https://gist.github.com/62mkv/de295ffd8dae75234d091713b2a226fb, based on research done thus far. I have to switch to different tasks now :( any feedback on the gist is welcome!

[prakashtanaji]

Just to clarify/confirm, there are two kinds of trust store settings here.

(1) Used for 2-way SSL where a client also need to provides its certificate to server to identify itself. For which the env properties(server.ssl.trust-store & server.ssl.trust-store-password) can be set. This may be used in conjunction with the key store and need SSL enabled.
(2) Used by the client to trust the server which is hosted over SSL. The client will use the certificate from the trust store(this path/password for this cannot be obtained from the above env. properties) to establish chain of trust. For this to work one need to set the system properties - javax.net.ssl.trustStore & javax.net.ssl.trustStorePassword.

There is no environment variable available today to directly set the system properties above, which will be good to have.

[wilkinsona]

(1) Used for 2-way SSL where a client also need to provides its certificate to server to identify itself. For which the env properties(server.ssl.trust-store & server.ssl.trust-store-password) can be set. This may be used in conjunction with the key store and need SSL enabled.

I don't think that server.ssl.trust-* properties should be used to configure a client-side trust store.

Used by the client to trust the server which is hosted over SSL. The client will use the certificate from the trust store(this path/password for this cannot be obtained from the above env. properties) to establish chain of trust. For this to work one need to set the system properties - javax.net.ssl.trustStore & javax.net.ssl.trustStorePassword.

I don't think we should rely on System properties to configure a client-side trust store as the effects of the system properties are too broad. If we do something here it should be specific to a particular client or particular type of client.