کدام سمت پروکسی بازرسی گواهی را رد کرد؟

کلاینت به پروکسی بازرسی تأییدشده اعتماد می‌کند. با این حال درخواست به دلیل خطای گواهی شکست می‌خورد. هر دو واقعیت می‌توانند درست باشند: آن پروکسی رابطه TLS دیگری برای تأیید دارد.

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

در ترتیب رهگیری، واسطه TLS کلاینت را پایان می‌دهد و اتصال خود را به سمت جلو ایجاد می‌کند. کلاینت می‌تواند گواهی ارائه‌شده در سمت خود را بپذیرد، در حالی که پروکسی گواهی دریافتی از وب‌سایت را رد می‌کند.

خطای تأییدکننده را بخوانید

مشخص کنید کدام فرآیند زنجیره یا نام میزبان ناموفق را گزارش کرده است. صفحه خطای تولیدشده توسط پروکسی می‌تواند از طریق اتصال معتبر با موفقیت به کلاینت برسد. تغییر دوباره فایل CA کلاینت، پیکربندی اعتماد بالادست پروکسی را به‌روزرسانی نمی‌کند.

برای مثال Mitmproxy گزینه‌های جداگانه اعتماد بالادست را مستند می‌کند، از جمله ssl_verify_upstream_trusted_ca. مدیر مربوطه می‌تواند اعتماد تأییدشده برای سرویس بالادست را با حفظ تأیید تنظیم کند. محصول پروکسی دیگر به رابط مربوط به خود نیاز دارد.

نام واقعی مقصد و زنجیره را هم بررسی کنید. سرویس خصوصی فاقد گواهی میانی، گواهی منقضی‌شده و صادرکننده خصوصی ناشناخته هر کدام ترمیم متفاوتی می‌خواهند. استثنای عمدی برای یک سرویس خصوصی نباید بی‌صدا به پذیرش جهانی همه گواهی‌ها تبدیل شود.

تونل ساده CONNECT متفاوت است

تونل ارسال مات، TLS مقصد را به این شکل تقسیم نمی‌کند. برنامه معمولاً خود آن نشست TLS سرتاسری را مذاکره و تأیید می‌کند. نخست مشخص کنید که آیا رهگیری واقعاً بخشی از مسیر است، به جای اعمال تنظیمات پروکسی بازرسی روی هر واسطه‌ای.

دو نتیجه تأیید را جداگانه ثبت کنید. «گواهی پروکسی قابل اعتماد است» به پرسش سمت کلاینت پاسخ می‌دهد؛ اما گواهی نمی‌کند که پروکسی هنگام اتصال بالادست چه دید.