Hvem sender klientcertifikatet gennem en proxy?
Hold destinationens mTLS-legitimationsoplysninger adskilt fra proxyens legitimationsoplysninger og fra certifikater, som Apache bruger, når det opretter sin egen opstrøms TLS-session.
Ved almindelig HTTPS gennem CONNECT sender applikationen webstedets klientcertifikat under sit eget TLS-håndtryk med destinationen. Proxien videresender bytes; den bliver ikke automatisk webstedets TLS-klient.
| Legitimationsoplysning | Ejer/forbindelse |
|---|---|
| Proxy-brugernavn/adgangskode | Klientens adgang til proxien. |
| Webstedets klientcertifikat og private nøgle | Applikationens TLS-session med destinationen. |
| Proxyserverens opstrøms klientcertifikat | En TLS-session, som proxien selv starter. |
Disse roller kan sameksistere. Det er ikke nødvendigt at uploade webstedets private nøgle til en simpel tunnelproxy for at få mTLS til destinationen til at virke. Efter CONNECT-overdragelsen bruger du applikationens normale opsætning af klientcertifikat til destinationen og fortsætter med at verificere webstedets servercertifikat.
Apaches SSLProxyMachineCertificateFile leverer legitimationsoplysninger, når Apache opretter sin egen opstrøms TLS-session. Råd om den fil beviser ikke, at enhver klient, der bruger en uigennemsigtig videresendelsestunnel, skal konfigurere den.
TLS-aflytning afslutter en session hos en mellemled og ændrer dette ejerskab. Fastslå, om den krævede klientidentitet kan passere gennem den ordning, i stedet for at antage, at kopiering af et certifikat bevarer end-to-end-godkendelse.
Ved en fejl skal du notere, om anmodningen stoppede ved proxy-login, ved destinationens TLS eller ved den senere applikationsudveksling. Anbring legitimationsoplysningen på den forbindelse, der faktisk anmoder om den.