OpenSSL s_client: خطای 403 پراکسی پیش از TLS مقصد رخ می‌دهد
پاسخ 403 در CONNECT از طریق پراکسی OpenSSL را شکستی در مرحلهٔ تونل بدانید و گواهی مقصد را بر پایهٔ دست‌دهی‌ای که هرگز آغاز نشده تشخیص ندهید.
اگر openssl s_client در پاسخ به درخواست CONNECT خود از طریق پراکسی، HTTP 403 دریافت کند، از همان رد شروع کنید. تونل درخواستی برقرار نشده است.
با -proxy، s_client نخست از پراکسی HTTP می‌خواهد به مقصدی که با -connect مشخص شده وصل شود. تنها پاسخ موفق CONNECT است که این تبادل را به تونلی برای دست‌دهی TLS مقصد تبدیل می‌کند.
این ترتیب خروجی‌ای را توضیح می‌دهد که در غیر این صورت گیج‌کننده است: خطای پراکسی و سپس سرفصل‌های مربوط به TLS، نبودِ گواهی همتا، یا خط تأییدی که ظاهراً آرامش‌بخش است. این فیلدها ثابت نمی‌کنند که گواهی مقصد دریافت و تأیید شده است. عملیات در مرحله‌ای پیش‌تر متوقف شده است.
پاسخ پراکسی و میزبان و درگاه مقصد درخواستی را ثبت کنید. 403 توجه را به تصمیم دسترسی پراکسی جلب می‌کند؛ 407 درخواست احراز هویت پراکسی می‌کند. هیچ‌یک با خاموش‌کردن تأیید گواهی مقصد درست نمی‌شود.
وقتی بررسی تبادل مجاز است، خروجی -debug در s_client می‌تواند به آشکارکردن رد کمک کند. هرگونه اعتبارنامهٔ پراکسی را بیرون از ردهای مشترک نگه دارید. تونل موفق باز هم پس از آن به ارزیابی مستقل TLS و گواهی نیاز دارد، اما تا زمانی که واقعاً به آن مرحله نرسیده‌ایم، زنجیرهٔ گواهی مقصدی برای تشخیص وجود ندارد.