Kven sender klientcertifikatet gjennom ein proxy?
Hald mTLS-legitimasjonen til destinasjonen skild frå proxy-legitimasjonen og frå sertifikata Apache brukar når det lagar si eiga oppstraums TLS-økt.
Ved vanleg HTTPS gjennom CONNECT sender applikasjonen klientcertifikatet til nettstaden under sitt eige TLS-handtrykk med destinasjonen. Proxyen sender berre vidare byte; ho vert ikkje automatisk TLS-klienten til nettstaden.
| Legitimasjon | Eigar/tilkopling |
|---|---|
| Proxy-brukarnamn/passord | Tilgangen til klienten til proxyen. |
| Klientcertifikat og privat nøkkel til nettstaden | TLS-økta til applikasjonen med destinasjonen. |
| Oppstraums klientcertifikat til proxyserveren | Ei TLS-økt som proxyen sjølv startar. |
Desse rollene kan finnast samstundes. Det er ikkje naudsynt å lasta opp den private nøkkelen til nettstaden til ein enkel tunnelproxy for at mTLS mot destinasjonen skal verka. Etter CONNECT-overleveringa brukar du det vanlege oppsettet for klientcertifikat mot destinasjonen i applikasjonen og held fram med å stadfesta servercertifikatet til nettstaden.
SSLProxyMachineCertificateFile til Apache leverer legitimasjon når Apache lagar si eiga oppstraums TLS-økt. Råd om den fila provar ikkje at kvar klient som brukar ein ugjennomsiktig videresendingstunnel, må setja henne opp.
TLS-avlytting avsluttar ei økt hjå ein mellommann og endrar dette eigarskapet. Fastslå om den påkravde klientidentiteten kan passera gjennom denne ordninga, i staden for å gå ut frå at kopiering av eit sertifikat held på autentisering frå ende til ende.
Ved feil, skriv ned om førespurnaden stoppa ved proxy-innlogging, ved TLS-en til destinasjonen eller ved den seinare applikasjonsutvekslinga. Set legitimasjonen på tilkoplinga som faktisk ber om han.