خطأ 403 في OpenSSL s_client عبر الوسيط يقع قبل TLS الخاص بالوجهة
فسّر الاستجابة 403 على طلب CONNECT عبر وسيط OpenSSL كفشل في مرحلة النفق، وتجنّب تشخيص شهادة الوجهة اعتمادًا على مصافحة لم تبدأ أصلًا.
إذا تلقّى openssl s_client استجابة HTTP 403 ردًّا على طلب CONNECT عبر الوسيط، فابدأ من هذا الرفض. لم يُنشأ النفق المطلوب.
مع -proxy يطلب s_client أولًا من وسيط HTTP الاتصال بالوجهة المحددة عبر -connect. ولا يحوّل هذا التبادل إلى نفق لمصافحة TLS الخاصة بالوجهة إلا استجابة CONNECT ناجحة.
يفسّر هذا الترتيب مخرجات مربكة لولا ذلك: خطأ من الوسيط تليه عناوين متعلقة بـ TLS، أو غياب شهادة النظير، أو سطر تحقّق يبدو مطمئنًا. هذه الحقول لا تثبت أن شهادة الوجهة استُلمت وجرى التحقق منها. فقد توقفت العملية في مرحلة أسبق.
سجّل استجابة الوسيط واسم مضيف الوجهة ومنفذها المطلوبين. فالاستجابة 403 توجّه الانتباه إلى قرار الوسيط بشأن الوصول؛ أما الاستجابة 407 فتطلب مصادقة الوسيط. ولا يُصلح أيًّا منهما تعطيل التحقق من شهادة الوجهة.
حين يُسمح بفحص التبادل، قد يساعد خرج -debug في s_client على كشف الرفض. أبقِ أي بيانات اعتماد للوسيط خارج الآثار المشتركة. سيظل النفق الناجح بحاجة لاحقًا إلى تقييمه الخاص لـ TLS والشهادات، لكن لا توجد سلسلة شهادات هدف لتشخيصها قبل بلوغ تلك المرحلة فعليًا.