پیش از تغییر بستهٔ CA مشخص کنید کدام دست‌دهی TLS شکست خورده است. گواهی پراکسی و گواهی وب‌سایت ممکن است روی اتصال‌های جداگانه بررسی شوند.

پراکسی و مقصدبررسی‌های TLS
پراکسی HTTP برای مقصد HTTPSپس از CONNECT، گواهی مقصد را از داخل تونل تأیید کنید.
پراکسی HTTPS برای مقصد HTTPSابتدا TLS به پراکسی را تأیید کنید؛ پس از باز شدن تونل، نشست جداگانهٔ TLS به مقصد را تأیید کنید.

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

curl برای این دو اتصال گزینه‌های CA جداگانه دارد:

curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/

--proxy-cacert مبنای اعتماد به پراکسی را فراهم می‌کند و --cacert مبنای اعتماد به مقصد را. نقطهٔ اتصال و فایل‌های مثال را با مقادیر سازوکار اعتماد موردنظرتان جایگزین کنید. اگر اعتماد سیستم کافی است، بسته‌های سفارشی لازم نیستند.

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

رد شدن اتصال پورت یا CONNECT به مرحله‌ای زودتر مربوط است؛ تغییر گواهی‌ها آن را رفع نمی‌کند. برعکس، پس از تأیید TLS مقصد، خطای HTTP وب‌سایت به پاسخ دریافت‌شده مربوط است، نه تنظیم دوبارهٔ CA.

مقالات مرتبط