કઈ બાજુએ નિરીક્ષણ પ્રોક્સીએ પ્રમાણપત્ર નકાર્યું?

ક્લાયન્ટ મંજૂર નિરીક્ષણ પ્રોક્સી પર ભરોસો કરે છે. તેમ છતાં પ્રમાણપત્રની ભૂલને કારણે વિનંતી નિષ્ફળ જાય છે. બંને હકીકતો સાચી હોઈ શકે: તે પ્રોક્સી પાસે ચકાસવા માટે બીજો TLS સંબંધ છે.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

ઇન્ટરસેપ્શન ગોઠવણીમાં મધ્યસ્થ ક્લાયન્ટનું TLS સમાપ્ત કરે છે અને આગળ પોતાનું જોડાણ બનાવે છે. ક્લાયન્ટ પોતાની બાજુએ રજૂ કરાયેલું પ્રમાણપત્ર સ્વીકારી શકે છે, જ્યારે પ્રોક્સી વેબસાઇટ પરથી મળેલું પ્રમાણપત્ર નકારે છે.

ચકાસનારની ભૂલ વાંચો

કઈ પ્રક્રિયાએ નિષ્ફળ શૃંખલા અથવા હોસ્ટનામની જાણ કરી તે નક્કી કરો. પ્રોક્સીએ બનાવેલું ભૂલ પૃષ્ઠ માન્ય કનેક્શન પર ક્લાયન્ટ સુધી સફળતાપૂર્વક પહોંચી શકે છે. ક્લાયન્ટની CA ફાઈલ ફરી બદલવાથી પ્રોક્સીની અપસ્ટ્રીમ ટ્રસ્ટ રૂપરેખા અપડેટ થતી નથી.

ઉદાહરણ તરીકે Mitmproxy અલગ અપસ્ટ્રીમ ટ્રસ્ટ વિકલ્પોનું દસ્તાવેજીકરણ કરે છે, જેમાં ssl_verify_upstream_trusted_caનો સમાવેશ થાય છે. યોગ્ય વ્યવસ્થાપક ચકાસણી જાળવી રાખીને અપસ્ટ્રીમ સેવા માટે મંજૂર ટ્રસ્ટ ગોઠવી શકે છે. બીજા પ્રોક્સી ઉત્પાદને તેના અનુરૂપ ઇન્ટરફેસની જરૂર છે.

વાસ્તવિક ગંતવ્ય નામ અને શૃંખલા પણ તપાસો. મધ્યવર્તી વગરની ખાનગી સેવા, સમાપ્ત થયેલું પ્રમાણપત્ર અને અજાણ્યા ખાનગી ઇશ્યુઅરને જુદા જુદા સમારકામની જરૂર પડે છે. એક ખાનગી સેવા માટેનું ઇચ્છિત અપવાદ ચૂપચાપ દરેક પ્રમાણપત્રની વૈશ્વિક સ્વીકૃતિ ન બનવું જોઈએ.

સાદો CONNECT ટનલ અલગ છે

અપારદર્શક ફોરવર્ડ ટનલ ગંતવ્ય TLSને આ રીતે વિભાજિત કરતું નથી. એપ્લિકેશન સામાન્ય રીતે તે એન્ડ-ટુ-એન્ડ TLS સત્ર જાતે જ વાટાઘાટ કરે છે અને ચકાસે છે. કોઈપણ મધ્યસ્થ પર નિરીક્ષણ-પ્રોક્સી સેટિંગ્સ લાગુ કરવાને બદલે પહેલા નક્કી કરો કે ઇન્ટરસેપ્શન ખરેખર માર્ગનો ભાગ છે કે નહીં.

બંને ચકાસણી પરિણામો અલગથી નોંધો. “પ્રોક્સીનું પ્રમાણપત્ર વિશ્વસનીય છે” એ ક્લાયન્ટ બાજુના પ્રશ્નનો જવાબ આપે છે; પ્રોક્સીએ ઉપર જોડાતી વખતે શું જોયું તેની તે પ્રમાણિતતા આપતું નથી.