പ്രോക്സി വഴി ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് അയയ്ക്കുന്നത് ആരാണ്?

സാധാരണ CONNECT വഴിയുള്ള HTTPS-ൽ, ആപ്ലിക്കേഷൻ അതിന്റെ സ്വന്തം ലക്ഷ്യ TLS ഹാൻഡ്‌ഷേക്കിനിടയിൽ വെബ്‌സൈറ്റിന്റെ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് അയയ്ക്കുന്നു. പ്രോക്സി ബൈറ്റുകൾ മാത്രം കൈമാറുന്നു; അത് സ്വയമേവ വെബ്‌സൈറ്റിന്റെ TLS ക്ലയന്റായി മാറുന്നില്ല.

ഈ റോളുകൾ ഒരുമിച്ച് നിലനിൽക്കാം. ലക്ഷ്യ mTLS പ്രവർത്തിക്കാൻ വെബ്‌സൈറ്റിന്റെ സ്വകാര്യ കീ ലളിതമായ ടണൽ പ്രോക്സിയിലേക്ക് അപ്‌ലോഡ് ചെയ്യേണ്ടതില്ല. CONNECT കൈമാറ്റത്തിന് ശേഷം, ആപ്ലിക്കേഷന്റെ സാധാരണ ലക്ഷ്യ ക്ലയന്റ്-സർട്ടിഫിക്കറ്റ് കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് വെബ്‌സൈറ്റ് സെർവർ സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുന്നത് തുടരുക.

Apache-ന്റെ SSLProxyMachineCertificateFile, Apache സ്വന്തം അപ്സ്ട്രീം TLS സെഷൻ സൃഷ്ടിക്കുമ്പോൾ ക്രെഡൻഷ്യലുകൾ നൽകുന്നു. ആ ഫയലിനെക്കുറിച്ചുള്ള ഉപദേശം, അതാര്യമായ ഫോർവേഡ് ടണൽ ഉപയോഗിക്കുന്ന എല്ലാ ക്ലയന്റും അത് കോൺഫിഗർ ചെയ്തിരിക്കണമെന്ന് തെളിയിക്കുന്നില്ല.

TLS ഇടപെടൽ ഒരു ഇടനിലക്കാരനിൽ സെഷൻ അവസാനിപ്പിക്കുകയും ഈ ഉടമസ്ഥത മാറ്റുകയും ചെയ്യുന്നു. സർട്ടിഫിക്കറ്റ് പകർത്തുന്നത് അറ്റത്തുനിന്ന് അറ്റത്തോളമുള്ള പ്രാമാണീകരണം നിലനിർത്തുമെന്ന് അനുമാനിക്കുന്നതിന് പകരം, ആവശ്യമായ ക്ലയന്റ് ഐഡന്റിറ്റിക്ക് ആ ക്രമീകരണത്തിലൂടെ കടന്നുപോകാനാകുമോ എന്ന് നിർണ്ണയിക്കുക.

പരാജയമുണ്ടായാൽ, അഭ്യർത്ഥന പ്രോക്സി ലോഗിനിലോ, ലക്ഷ്യ TLS-ലോ, അതോ പിന്നീടുള്ള ആപ്ലിക്കേഷൻ കൈമാറ്റത്തിലോ നിന്നുവെന്ന് രേഖപ്പെടുത്തുക. ക്രെഡൻഷ്യൽ യഥാർത്ഥത്തിൽ അത് ആവശ്യപ്പെടുന്ന കണക്ഷനിൽ വയ്ക്കുക.