Unfortunately, client certificates are not supported by tlsproxy yet, but we plan to add some kind of support for this.
However, what you want to achieve is not technically possible in a straight way.
You probably want this:
If the server requests a client certificate, the tlsproxy will requests a client certificate as well (on inbound tunnel). The tlsproxy simply passes the certificate selected by the client application to the server (on outbound tunnel).
This is not possible. For client certificate authentication you need access to the private key associated with the client certificate. But the tlsproxy will receive (from the client application) only public part of the selected client certificate. Since the tlsproxy has no access to the associated private key, it cannot complete the client certificate authentication with the target server.
The possible solutions can be divided into two cases (i will use CCA for Client Certificate Authentication further):
The tlsproxy will gain access to the private keys of the client certificates used for CCA. This solution does not require any modification of client nor server.
The tlsproxy will have no access to the required private keys and it will not perform CCA on outbound tunnel. This solution requires to modify server logic (and possibly client logic).
Couple solutions for case 1:
1A. The tlsproxy will always use one defined client certificate for outbound tunnel (no CCA on inbound tunnel).
1B. The tlsproxy will use client certificate for outbound tunnel selected by some criteria, for example by IP address (no CCA on inbound tunnel).
1C. The tlsproxy will use client certificate for outbound tunnel based on Subject/Thumbprint/etc. of the client certificate received on the inbound tunnel.
Note:
All the above solutions require that tlsproxy has access to private keys associated with the certificates used. Typically, you will need to store the .pfx certificate(s) at the tlsproxy location (disk, Certificate Storage, etc.) It can be acceptable for case 1A, but it can be security risk for case 1C where you need to store all the possible client certificates at one place.
Couple solutions for case 2:
2A. The tlsproxy will perform CCA on inbound tunnel and it sends the selected client certificate to the server in application data, for example as a HTTP header within the first HTTP request. It means that CCA is not performed on outbound tunnel. The service has to be modified to read the client certificate from the HTTP header.
2B. The tlsproxy will not perform CCA at all. After the TLS is negotiated, the client sends the certificate to the server using defined mechanism.
For example: just after connection, client must issue "POST /cca.asp" where the certificate is sent in the POST request data. Then communication goes as normal: "GET /default.html".
In this case, both the client application and the service has to be modified.
Note:
In both above solutions, there is no verification that the client is really the one who has access to the provided client certificate. It still can be suitable if both proxy+service are in the DMZ.
The case 2B can be extended to support client certificate validation like this:
1. after connect, client requests "GET /cca.asp"
2. server replies with random data
3. client signs the received random data using desired client certificate and sends the signature + the certificate using "POST /cca.asp"
4. server validates the signature and authorizes the client
5. normal HTTP communication follows