Hver sendir biðlara skírteinið í gegnum proxí?
Haltu mTLS-skírteinum áfangastaðar aðskildum frá skírteinum proxísins og frá skírteinum sem Apache notar þegar það býr til sína eigin TLS-lotu uppstreymis.
Í venjulegri HTTPS um CONNECT sendir forritið biðlara skírteini vefsvæðisins meðan á eigin TLS-handabandi þess við áfangastað stendur. Proxíið miðlar aðeins bætum; það verður ekki sjálfkrafa TLS-biðlari vefsvæðisins.
| Skírteini | Eigandi/tenging |
|---|---|
| Notandanafn/lykilorð proxís | Aðgangur biðlarans að proxíinu. |
| Biðlara skírteini og einkalykill vefsvæðisins | TLS-lota forritsins við áfangastaðinn. |
| Uppstreymis biðlara skírteini proxíþjónsins | TLS-lota sem proxíið sjálft hefur frumkvæði að. |
Þessi hlutverk geta verið til samtímis. Ekki þarf að hlaða einkalykli vefsvæðisins upp á einfalt gönguproxí til að mTLS til áfangastaðar virki. Eftir CONNECT-afhendinguna skal nota venjulega uppsetningu áfangastaðar fyrir biðlara skírteini í forritinu og halda áfram að sannprófa skírteini þjóns vefsvæðisins.
SSLProxyMachineCertificateFile hjá Apache veitir skírteini þegar Apache býr til sína eigin TLS-lotu uppstreymis. Ráð um þá skrá sannar ekki að sérhver biðlari sem notar ógagnsæja framgöngugöng skuli stilla hana.
TLS-afhlustun endar lotu hjá millilið og breytir þessari eign. Athugaðu hvort tilskilin biðlaraauðkenni geti farið í gegnum þetta fyrirkomulag í stað þess að gera ráð fyrir að afritun skírteinis varðveiti auðkenningu enda á milli.
Ef bilun verður skal skrá hvort beiðnin stöðvaðist við innskráningu í proxíið, við TLS áfangastaðar eða við síðari forritaskipti. Settu skírteinið á þá tengingu sem raunverulega biður um það.