============= Problem Background ====================
When testing a standalone nginx (as a reverse proxy) - using the latest version (1.13) it all works fine but when using the 1.11 release (which is the apicast/openresty version) it fails. It also fails when using apicast.

This still in investigation phase, but their current idea of why it’s working in 1.13 and not in 1.11 (and apicast) is because of a recent new feature/fix in nginx.

http://nginx.org/en/CHANGES

Changes with nginx 1.13.0 25 Apr 2017

*) Change: SSL renegotiation is now allowed on backend connections.

============================

First step is to verify the above issue.

There we need feedback on a potential delivery timeline:

1. Based on the mutual SSL installation guide (non-productized). Potentially this will require a future APIcast image which in turn contains OpenResty which has been updated to include the latest Nginx. We should push in the forums to get OpenResty updated, but it is not in our control. Then it is a question how long after the OpenResty release it is feasible for the APIcast images to be updated (stick to standard cycles for APM, or release separately?)
2. Feasibility and timeline to productize mutual SSL. Strictly this is not a hard requirement from the customer at this stage.

For the workaround in the interim (needed in a matter of days/weeks for the PoC to close the deal by October). This needs to demonstrate support for their backend APIs without any changes to the current mutual SSL:

1. The best workaround I can think of is to point APIcast to another layer of Nginx 1.13.1 as a reverse proxy to handle the mutual SSL. If we go this route they want some load test numbers to validate it won't impact latency significantly. As long as Nginx runs on a different port on the same instance to avoid a network hop, I assume this should be negligible.
2. Is there any other possibility to to a Native installation based on the latest Nginx rather than on OpenResty?