ردیابی خطاهای پروکسی در بررسیهای گواهی CRL و OCSP
واکشی CRL یا OCSP را زیر حساب تأییدکننده ردیابی کنید وقتی برنامه به پروکسی خود میرسد اما اعتبارسنجی گواهی نمیتواند کامل شود.
درخواست یک وبسایت میتواند به پروکسی خود برسد و باز هم شکست بخورد، زیرا بررسی گواهی به یک درخواست شبکهای دیگر نیاز دارد. واکشی CRL یا OCSP ممکن است از طریق یک مؤلفه پلتفرم با حساب و سیاست پروکسی متفاوت از کلاینت HTTP برنامه انجام شود.
با خطای دقیق زنجیره شروع کنید. ابطالشده معنایی متفاوت از ناتوانی در دریافت اطلاعات ابطال فعلی دارد. انقضا و صادرکنندهٔ غیرقابلاعتماد نیز مشکلات دیگری هستند. فقط خطای واکشی است که ردیابی مسیر گمشده به یک URL وضعیت را میطلبد.
برای آن خطا، سه چیز را همزمان مشخص کنید: URL در حال واکشی، مؤلفهای که واکشی را انجام میدهد و هویت فرایند آن. اینکه یک مرورگر URL را زیر حساب تعاملی شما با موفقیت باز کند ثابت نمیکند که یک سرویس میتواند به همان پروکسی احراز هویت کند.
اگر مؤلفهٔ شناساییشده از WinHTTP استفاده میکند، سیاست اعمالشده بر آن را بررسی کنید. پیکربندی ایستای پروکسی و ارزیابی خودکار پروکسی برای هر URL سازوکارهای جداگانهای هستند. پیکربندی پشتیبانیشده را برای حساب موردنظر اعمال کنید؛ کپی کردن تنظیمات مرورگر یا تغییر یک زمان اجرای نامرتبط میتواند واکشی واقعی را دستنخورده بگذارد.
در .NET، UrlRetrievalTimeout در سیاست زنجیره انتظار برای تأیید برخط یا واکشی CRL را کنترل میکند. تمدید مهلت معمول پاسخ HTTP همان تایمر را تمدید نمیکند و تمدید تایمر واکشی نه اعتبارنامهٔ پروکسی فراهم میکند و نه مسیر.
یک پروکسی HTTPS میتواند این وابستگی را حتی پیش از TLS مقصد آشکار کند: اعتماد به اتصال پروکسی ممکن است خودش نیازمند واکشی اطلاعات ابطال باشد. در آن مرحله دسترسی واکشی پشتیبانیشده و ترتیب اعتماد را بازگردانید. غیرفعال کردن بررسی ابطال سیاست گواهی را تغییر میدهد؛ واکشی ناموفق را بازنمیگرداند.