1

Due to some quirks with a particular cloud OAuth2 identity provider, I need to perform "split-horizon" interactions where the main OAuth2 token exchange is directed to the cloud provider (which uses a globally valid TLS certificate) and the user-info query is directed to an internal microservice that is using a certificate signed by the corporate CA.

We have general-purpose downstream API calls to microservices using internal certificates working by providing the corporate root and intermediate CA certificates to the WebClient we're using, but when Spring Security tries to access the user-info endpoint, it is using a WebClient instance that only trusts the usual global CAs, and so at login we get errors indicating inability to find a trust root:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Since the allowable corporate CAs vary by environment (dev, acceptance, production), we are trying to avoid having to build complete copies of the truststore in the CI pipeline and adding individual certificates; instead, we're hoping to find a way to provide the PEMs at runtime in a fashion similar to the Spring Cloud Gateway support for "known certificates".

How can we configure Spring Security to trust both the global set of CAs, so that it can perform the OAuth2 exchange with the public identity provider, and our corporate CA, so that it can also make user-info calls to our internal endpoint?

chrylis -cautiouslyoptimistic-
  • 75,269
  • 21
  • 115
  • 152

0 Answers0