Wie stuur die kliëntsertifikaat deur ’n instaanbediener?
Hou bestemming-mTLS-bewyse apart van instaanbedienerbewyse en van sertifikate wat Apache gebruik wanneer dit sy eie opwaartse TLS-sessie skep.
Met gewone HTTPS deur CONNECT stuur die toepassing die webwerf se kliëntsertifikaat tydens sy eie TLS-handdruk met die bestemming. Die instaanbediener stuur grepe aan; dit word nie outomaties die webwerf se TLS-kliënt nie.
| Bewys | Eienaar/verbinding |
|---|---|
| Instaanbedienergebruikersnaam/-wagwoord | Kliënttoegang tot die instaanbediener. |
| Webwerf se kliëntsertifikaat en private sleutel | Toepassing se TLS-sessie met die bestemming. |
| Instaanbediener se opwaartse kliëntsertifikaat | TLS-sessie wat die instaanbediener self begin. |
Hierdie rolle kan saam bestaan. Jy hoef nie die webwerf se private sleutel na ’n gewone tonnel-instaanbediener op te laai om bestemming-mTLS te laat werk nie. Ná die CONNECT-oordrag gebruik jy die toepassing se normale bestemming-kliëntsertifikaatkonfigurasie en hou jy aan om die webwerf se bedienersertifikaat te verifieer.
SSLProxyMachineCertificateFile verskaf bewys wanneer Apache sy eie opwaartse TLS-sessie skep. Raad oor dié lêer bewys nie dat elke kliënt met ’n ondeursigtige vorentoe-tonnel dit moet instel nie.
TLS-onderskepping beëindig ’n sessie by ’n tussenganger en verander hierdie eienaarskap. Bepaal of die vereiste kliëntidentiteit deur die rangskikking kan gaan eerder as om te aanvaar dat die kopiëring van ’n sertifikaat eind-tot-eind-verifikasie behou.
Teken by ’n fout aan of die versoek by proxy-aanmelding, bestemming-TLS of die latere toepassing-uitruiling gestop het. Plaas die bewys op die verbinding wat dit werklik versoek.