The Red Hat 3scale Support Team has been able to reproduce the issue.

Please find more information in the "Steps to Reproduce". It's possible to isolate the issue as being related to APIcast because the equivalent from 'curl' works:

1. Without using a Proxy:

$ env | grep -i "proxy"
<EMPTY>
$ curl https://server.cryptomix.com/secure/ --cert APIcast-client.crt --key APIcast-client.key 2>&1 | grep -i "</head>" -A 1
</head>
<br><span class="sslsuccess">SSL Authentication OK!</span><br><br>Technical information follows :<pre>Array

2. Using a Proxy:

$ export http_proxy="http://<PROXY>:<PORT>"
$ export https_proxy="http://<PROXY>:<PORT>"
$ curl https://server.cryptomix.com/secure/ --cert APIcast-client.crt --key APIcast-client.key 2>&1 | grep -i "</head>" -A 1
</head>
<br><span class="sslsuccess">SSL Authentication OK!</span><br><br>Technical information follows :<pre>Array

I have tested all versions from APIcast starting from 2.6 and was able to reproduce the issue. It's very likely that it affects previous versions as well.

Hence, APIcast should be able to send the client certificates from 'APICAST_PROXY_HTTPS_CERTIFICATE' and 'APICAST_PROXY_HTTPS_CERTIFICATE_KEY' to the Backend API regardless of whether a Forward Proxy is being used.

Please find attached the APIcast 2.8 logs from both a success (without using a Forward Proxy) and failure (using a Forward Proxy), respectively.

Developer notes:

• We will need at least openresty 1.21, which adds a new function that allows setting a certificate for cosocket
• When the proxy policy is in the chain, APIcast use lua code to construct the request and send it upstream. Therefore, there needs to be a way to retrieve certificates that have been established by the upstream MTLS policy. The best way to do this is to extend the apicast-nginx module with new ffi functions.