પ્રોક્સી દ્વારા ક્લાયન્ટ સર્ટિફિકેટ કોણ મોકલે છે?
ગંતવ્યના mTLS ઓળખપત્રોને પ્રોક્સીના ઓળખપત્રોથી અને Apache જ્યારે તેનું પોતાનું અપસ્ટ્રીમ TLS સેશન બનાવે ત્યારે વાપરે છે તે સર્ટિફિકેટોથી અલગ રાખો.
સામાન્ય CONNECT દ્વારા HTTPS માં, એપ્લિકેશન પોતાના ગંતવ્ય TLS હેન્ડશેક દરમિયાન વેબસાઇટનું ક્લાયન્ટ સર્ટિફિકેટ મોકલે છે. પ્રોક્સી ફક્ત બાઇટ્સ રિલે કરે છે; તે આપોઆપ વેબસાઇટનું TLS ક્લાયન્ટ બનતું નથી.
| ઓળખપત્ર | માલિક/કનેક્શન |
|---|---|
| પ્રોક્સી વપરાશકર્તાનામ/પાસવર્ડ | પ્રોક્સીમાં ક્લાયન્ટનો પ્રવેશ. |
| વેબસાઇટનું ક્લાયન્ટ સર્ટિફિકેટ અને ખાનગી કી | ગંતવ્ય સાથે એપ્લિકેશનનું TLS સેશન. |
| પ્રોક્સી સર્વરનું અપસ્ટ્રીમ ક્લાયન્ટ સર્ટિફિકેટ | પ્રોક્સી પોતે શરૂ કરે તે TLS સેશન. |
આ ભૂમિકાઓ સાથે રહી શકે છે. ગંતવ્ય mTLS કામ કરે તે માટે વેબસાઇટની ખાનગી કી સાદા ટનલિંગ પ્રોક્સી પર અપલોડ કરવાની જરૂર નથી. CONNECT હસ્તાંતરણ પછી, એપ્લિકેશનની સામાન્ય ગંતવ્ય ક્લાયન્ટ-સર્ટિફિકેટ ગોઠવણી વાપરો અને વેબસાઇટ સર્વર સર્ટિફિકેટ ચકાસવાનું ચાલુ રાખો.
Apache નું SSLProxyMachineCertificateFile જ્યારે Apache પોતાનું અપસ્ટ્રીમ TLS સેશન બનાવે ત્યારે ઓળખપત્રો પૂરા પાડે છે. તે ફાઇલ વિશેની સલાહ એ સાબિત કરતી નથી કે અસ્પષ્ટ ફોરવર્ડ ટનલ વાપરતા દરેક ક્લાયન્ટે તેને ગોઠવવું જ પડે.
TLS અટકાવ મધ્યસ્થ પર સેશન સમાપ્ત કરે છે અને આ માલિકી બદલે છે. સર્ટિફિકેટની નકલ કરવાથી છેડાથી-છેડા સુધીની પ્રમાણીકરણ જળવાય છે એમ માનવાને બદલે નક્કી કરો કે જરૂરી ક્લાયન્ટ ઓળખ તે ગોઠવણીમાંથી પસાર થઈ શકે છે કે નહીં.
નિષ્ફળતા વખતે, વિનંતી પ્રોક્સી લોગિન પર, ગંતવ્ય TLS પર કે પછીના એપ્લિકેશન વિનિમય પર અટકી હતી કે નહીં તે નોંધો. ઓળખપત્રને તે કનેક્શન પર મૂકો જે ખરેખર તેની માંગ કરે છે.