Chi invia il certificato client attraverso un proxy?
Tieni separati i certificati mTLS della destinazione dalle credenziali del proxy e dai certificati usati da Apache per la propria sessione TLS upstream.
Con il normale HTTPS tramite CONNECT, l’applicazione invia il certificato client del sito durante il proprio handshake TLS con la destinazione. Il proxy inoltra i byte; non diventa automaticamente il client TLS del sito.
| Credenziale | Proprietario/connessione |
|---|---|
| Nome utente/password del proxy | Accesso del client al proxy. |
| Certificato client e chiave privata del sito | Sessione TLS dell’applicazione con la destinazione. |
| Certificato client upstream del server proxy | Sessione TLS avviata dal proxy stesso. |
Questi ruoli possono coesistere. Non serve caricare la chiave privata del sito su un proxy di tunneling semplice per far funzionare il mTLS della destinazione. Dopo il passaggio CONNECT, usa la normale configurazione del certificato client di destinazione e continua a verificare il certificato server del sito.
SSLProxyMachineCertificateFile fornisce le credenziali quando Apache crea la propria sessione TLS upstream. Le indicazioni su quel file non dimostrano che ogni client che usa un tunnel diretto opaco debba configurarlo.
L’intercettazione TLS termina una sessione presso un intermediario e cambia questa proprietà. Verifica se l’identità client richiesta può attraversare quell’assetto invece di presumere che copiare un certificato preservi l’autenticazione end-to-end.
In caso di errore, registra se la richiesta si è fermata al login del proxy, al TLS della destinazione o allo scambio applicativo successivo. Metti la credenziale sulla connessione che la richiede davvero.