Cine trimite certificatul de client printr-un proxy?
Țineți acreditările mTLS ale destinației separate de acreditările proxy-ului și de certificatele pe care Apache le folosește când își creează propria sesiune TLS către amonte.
În HTTPS prin CONNECT obișnuit, aplicația trimite certificatul de client al site-ului în timpul propriului handshake TLS cu destinația. Proxy-ul doar retransmite octeți; nu devine automat clientul TLS al site-ului.
| Acreditare | Proprietar/conexiune |
|---|---|
| Nume de utilizator/parolă proxy | Accesul clientului la proxy. |
| Certificatul de client și cheia privată ale site-ului | Sesiunea TLS a aplicației cu destinația. |
| Certificatul de client amonte al serverului proxy | O sesiune TLS pe care proxy-ul o inițiază singur. |
Aceste roluri pot coexista. Încărcarea cheii private a site-ului pe un proxy de tunel simplu nu este necesară pentru ca mTLS către destinație să funcționeze. După predarea CONNECT, folosiți configurația obișnuită de certificat de client pentru destinație din aplicație și continuați să verificați certificatul de server al site-ului.
SSLProxyMachineCertificateFile din Apache furnizează acreditări când Apache își creează propria sesiune TLS către amonte. Sfatul despre acel fișier nu demonstrează că fiecare client care folosește un tunel de redirecționare opac trebuie să îl configureze.
Interceptarea TLS încheie o sesiune la un intermediar și schimbă această proprietate. Stabiliți dacă identitatea de client necesară poate trece prin acea aranjare, în loc să presupuneți că copierea unui certificat păstrează autentificarea de la un capăt la altul.
La o defecțiune, notați dacă cererea s-a oprit la autentificarea proxy, la TLS-ul destinației sau la schimbul ulterior al aplicației. Puneți acreditarea pe conexiunea care o solicită de fapt.