CRL અને OCSP પ્રમાણપત્ર તપાસમાં પ્રોક્સી નિષ્ફળતાઓનું ટ્રેસિંગ

વેબસાઇટ વિનંતી તેના પ્રોક્સી સુધી પહોંચી શકે અને તેમ છતાં નિષ્ફળ થઈ શકે, કારણ કે પ્રમાણપત્ર ચકાસણીને બીજી નેટવર્ક વિનંતીની જરૂર પડે છે. CRL અથવા OCSP પુનઃપ્રાપ્તિ એપ્લિકેશનના HTTP ક્લાયન્ટ કરતાં અલગ ખાતું અને પ્રોક્સી નીતિ ધરાવતા પ્લેટફોર્મ ઘટક દ્વારા ચાલી શકે છે.

ચોક્કસ ચેઇન ભૂલથી શરૂ કરો. રદ કરેલ એ વર્તમાન રદ કરવાની માહિતી મેળવી શકાતી નથી કરતાં કંઈક અલગ છે. સમાપ્તિ અને અવિશ્વસનીય જારીકર્તા ફરીથી અલગ સમસ્યાઓ છે. ફક્ત પુનઃપ્રાપ્તિ નિષ્ફળતા જ સ્ટેટસ URL તરફનો ખૂટતો માર્ગ ટ્રેસ કરવાની જરૂર છે.

તે નિષ્ફળતા માટે, ત્રણ વસ્તુઓ એકસાથે ઓળખો: જે URL પુનઃપ્રાપ્ત થઈ રહ્યું છે, જે ઘટક પુનઃપ્રાપ્તિ કરે છે અને તેની પ્રક્રિયા ઓળખ. તમારા ઇન્ટરેક્ટિવ ખાતા હેઠળ બ્રાઉઝર URL સફળતાપૂર્વક ખોલે તે સાબિત કરતું નથી કે કોઈ સેવા સમાન પ્રોક્સી પર પ્રમાણિત કરી શકે છે.

ઓળખાયેલ ઘટક WinHTTP વાપરે તો તેના પર લાગુ નીતિની તપાસ કરો. સ્થિર પ્રોક્સી રૂપરેખાંકન અને પ્રતિ-URL સ્વચાલિત પ્રોક્સી મૂલ્યાંકન અલગ પદ્ધતિઓ છે. ઇચ્છિત ખાતા માટે સમર્થિત રૂપરેખાંકન લાગુ કરો; બ્રાઉઝર સેટિંગ્સની નકલ કરવી અથવા અસંબંધિત રનટાઇમ બદલવું વાસ્તવિક પુનઃપ્રાપ્તિને અસ્પૃશ્ય રાખી શકે છે.

.NET માં ચેઇન નીતિ પર UrlRetrievalTimeout ઓનલાઇન ચકાસણી અથવા CRL પુનઃપ્રાપ્તિ માટેની રાહને નિયંત્રિત કરે છે. સામાન્ય HTTP પ્રતિસાદ સમયમર્યાદા લંબાવવાથી એ જ ટાઇમર લંબાતું નથી, અને પુનઃપ્રાપ્તિ ટાઇમર લંબાવવાથી પ્રોક્સી ઓળખપત્રો કે માર્ગ મળતો નથી.

HTTPS પ્રોક્સી આ અવલંબનને ગંતવ્ય TLS પહેલાં પણ દૃશ્યમાન બનાવી શકે છે: પ્રોક્સી જોડાણમાં વિશ્વાસને પોતે રદ માહિતીની પુનઃપ્રાપ્તિની જરૂર પડી શકે છે. તે તબક્કે સમર્થિત પુનઃપ્રાપ્તિ ઍક્સેસ અને વિશ્વાસ ગોઠવણી પુનઃસ્થાપિત કરો. રદ ચકાસણી નિષ્ક્રિય કરવાથી પ્રમાણપત્ર નીતિ બદલાય છે; નિષ્ફળ પુનઃપ્રાપ્તિ પુનઃસ્થાપિત થતી નથી.