Quem envia o certificado de cliente através de um proxy?
Separe as credenciais mTLS do destino das credenciais do proxy e dos certificados que o Apache usa ao criar sua própria sessão TLS upstream.
No HTTPS comum via CONNECT, a aplicação envia o certificado de cliente do site durante seu próprio handshake TLS com o destino. O proxy retransmite bytes; ele não se torna automaticamente o cliente TLS do site.
| Credencial | Proprietário/conexão |
|---|---|
| Nome de usuário/senha do proxy | Acesso do cliente ao proxy. |
| Certificado de cliente e chave privada do site | Sessão TLS da aplicação com o destino. |
| Certificado de cliente upstream do servidor proxy | Sessão TLS iniciada pelo próprio proxy. |
Esses papéis podem coexistir. Não é necessário enviar a chave privada do site a um proxy de túnel simples para fazer o mTLS do destino funcionar. Após a passagem CONNECT, use a configuração normal do certificado de cliente de destino na aplicação e continue verificando o certificado do servidor do site.
SSLProxyMachineCertificateFile fornece credenciais quando o Apache cria sua própria sessão TLS upstream. A orientação sobre esse arquivo não significa que todo cliente que usa um túnel direto opaco precise configurá-lo.
A interceptação TLS termina uma sessão em um intermediário e muda essa propriedade. Verifique se a identidade de cliente exigida pode atravessar esse arranjo, sem presumir que copiar um certificado preserve a autenticação ponta a ponta.
Em caso de falha, registre se a solicitação parou no login do proxy, no TLS do destino ou na troca posterior da aplicação. Coloque a credencial na conexão que realmente a solicita.