Hello? I have an issue with proxying client certificate to downstream service. I have service behind Spring Cloud Gateway (SCG) which need/want mutual tls authentication. But unfortunately when user executes requests through SCG mutual tls do not happen. On browser sight I did not get any client certificate request, so I assumed that it was not forwarded as a response from downstream service to a browser. I watched carefully on #852, #1091 and on your documentation. And seems that you solve how to make mutual tls from client to SCG and also from SCG to downstream service. But both of them not allow to make mutual tls from client to downstream service through SCG. Have you any ideas about how to solve it? Maybe it needs additional SCG Filter for proxying mutual tls auth ? Or any else solution? Thank you!
What does "does not happen" mean? Is there some exception happening?
There are no exceptions. It seems like mutual ssl authentication requests missed during proxying.
Spent the last day googling various topics looking for an answer with no luck. I think this issue (1637) is the correct feature request/issue I need as well, but verifying... Currently using spring boot/spring cloud gateway (Hoxton SR3), and I have a SCG path route listening on https (inbound not client auth, doesn't need to be). To process this client request, I need to connect outbound to an external webservice that does require mutual authentication. I can not see a way to solve this, although admittedly the documentation/others doing this seems rather sparse/not common. Is this the right issue I should be following?
Was considering spring cloud gateway outbound routing to a local port where stunnel is listening as a workaround, but that is a complete hack...
@cmhettinger you have complete control if you create your own reactor.netty.http.client.HttpClient bean.
https://projectreactor.io/docs/netty/snapshot/reference/index.html#_ssl_andtls
@violetagg may be able to provide better context.
Thanks for the quick reply - was hoping to get to this today, but being pulled in different directions (covid19 tasking interrupting the workforce, hoping you are doing well) so probably wont get to investigate for a day or two. Thanks for the reference, just once general question -- will this lock-in that config for all the outbound routes on SCG, or can we control it via specific routes? IE - all clients connect to us with https (not mutual auth), and we need to have /api/1 service reach out to downstream service via http, /api/2 reach downstream with https no mutual auth, and /api/3 reach out with https + clientauth. This is the behavior in a commercial product we are trying to replace with a custom app. Sorry for the fundamentals question...
Currently, there is only one HttpClient for all routes, but there is a protected method in NettyRoutingFilter that would allow you to do something different per route. https://github.com/spring-cloud/spring-cloud-gateway/blob/master/spring-cloud-gateway-core/src/main/java/org/springframework/cloud/gateway/filter/NettyRoutingFilter.java#L254
Thank you, very much appreciated
Thank you again - the bean mentioned above did allow us to configure outbound mutual authentication. I put a gist here for others.
I'm sure this isn't the place for a detailed discussion, but the "only one outbound client" setup along with the pool in the gateway is a bit awkward for our use-case. Not sure if enhancing that is part of any longer term plans, but for my two cents, those things would be better served being more route-oriented. Overall still liking the gateway... :)
I need exactly the same feature now (pass through client certificate to downstream service that requires mutual TLS).
@cmhettinger - so nice you managed to make it work by customizing HttpClient, will check your gist!
+1 for asking to provide native support in SCG for this feature.
Most helpful comment
Thank you again - the bean mentioned above did allow us to configure outbound mutual authentication. I put a gist here for others.
I'm sure this isn't the place for a detailed discussion, but the "only one outbound client" setup along with the pool in the gateway is a bit awkward for our use-case. Not sure if enhancing that is part of any longer term plans, but for my two cents, those things would be better served being more route-oriented. Overall still liking the gateway... :)