Problem

Using2-way SSL mutual authentication through a load balancer (LB) does not work.

Resolution

This is by design. As the "2-way" part of the protocol name implies, it does not permit a 3rd party to join the connection. Only the two key holders are permitted to communicate. This often comes up due to a requirement to use 2-way SSL in an environment with load balancers. Such a requirement is normally met by doing two sets of 2-way SSL connections, one between the client and LB using keys owned by the client and LB, then a separate connection between the LB and API Gateway using keys owned by the LB and gateway.

That then raises the question of how the API Gateway can identify the end client when the API Gateway sees all connections as coming from the LB and only receives the LB's certificate during the connection. For that purpose, many LBs have some provision to dump the original client certificate into an HTTP header, for example, as shown in this KB from F5. Your LB vendor can help you identify whether their product has such a feature. Once that is configured at the LB, the API Gateway can then retrieve the original client's certificate from the HTTP header and use that to identify the client as well as to perform any additional validation that might be desired. Because there is no set standard for this, the validation has to be written as a custom policy based on the output of the LB, but such a policy normally uses the filter Find Certificate, which is pointed at the HTTP header inserted by the LB, followed by Extract Certificate Attributes and whatever other certificate validation filters are desired.