fix: fixed forwarding of client certificate in case of mTLS

[ronsonx]

What's changed, or what was fixed?

Fixed forwarding of client certificate in case of mTLS: Envoy can populate x-forwarded-client-cert header. But this header was being discarded by Apigee. So, assigned the value of %DOWNSTREAM_PEER_CERT% command operator to a custom header named x-raw-client-cert in the envoy config.

• [X] I have run all the tests locally and they all pass.
• [X] I have followed the relevant style guide for my changes.

[g-greatdevaks]

@ronsonx Can you please provide more details as to what exactly you are trying to accomplish here? When you say that the header is being discarded by Apigee, do you mean that it is not visible as part of the debug information on Apigee or the request flow information?

Is your goal to get the certificate information as part of the headers?

[ronsonx]

@g-greatdevaks I found that the x-forwarded-client-cert populated by Envoy does not appear in trace nor is available for variable reassignment (request.header.x-forwarded-client-cert) in Apigee.

I attempted to resolve this issue by setting it to x-apigee.tls.client.raw.cert from Envoy to match with the Hybrid default. However, this too did not appear in the trace or become available for further processing.

I am assuming that Apigee is dropping these headers as part of some sanitization logic. As a solution, I set a custom header x-raw-client-cert. Please let me know if you have any questions or concerns about this issue.

[danistrebel]

Thanks for the suggestion @ronsonx! We have discussed this internally and decided that we don't want to change the behavior of the default implementation as this could lead to unintended consequences e.g. sending the client cert down to the backend service.

I'm inclined to adding this as a note to the mTLS solution's Readme file to let others know of the workaround.