Who Sends the Client Certificate Through a Proxy?
Keep destination mTLS credentials separate from proxy credentials and from certificates Apache uses when it creates its own upstream TLS session.
For ordinary HTTPS through CONNECT, the application sends the website's client certificate during its own destination TLS handshake. The proxy relays bytes; it does not automatically become the website's TLS client.
| Credential | Owner/connection |
|---|---|
| Proxy username/password | Client access to the proxy. |
| Website client certificate and private key | Application's TLS session with the destination. |
| Proxy server's upstream client certificate | A TLS session that the proxy itself initiates. |
These roles can coexist. Uploading the website private key to a plain tunneling proxy is not required to make destination mTLS work. After the CONNECT handoff, use the application's normal destination client-certificate configuration and continue verifying the website server certificate.
Apache's SSLProxyMachineCertificateFile supplies credentials when Apache creates its own upstream TLS session. Advice about that file does not establish that every client using an opaque forward tunnel must configure it.
TLS interception terminates a session at an intermediary and changes this ownership. Establish whether the required client identity can pass through that arrangement rather than assume copying a certificate preserves end-to-end authentication.
For a failure, record whether the request stopped at proxy login, destination TLS or the later application exchange. Put the credential on the connection that actually requests it.