remote-cert-tls server: ما الذي يتحقق منه في ملف تعريف OpenVPN
يتحقق التوجيه من الدور المشفَّر في شهادة النظير، لا من اسمها. قارن الدور وجذر الثقة وفحص اسم المضيف قبل تعطيل أي شيء.
تُجاب ثلاثة أسئلة مختلفة عن ثلاثة أجزاء مختلفة من ملف تعريف OpenVPN، ودمجها هو ما ينتهي به الناس إلى تعطيل فحص كان يعمل. هل شهادة النظير موقَّعة من الجهة التي أثق بها؟ هل تعلن تلك الشهادة دور خادم TLS؟ هل هو الخادم تحديدًا الذي قصدت الوصول إليه؟ remote-cert-tls server لا يجيب إلا عن السؤال الأوسط، وهو يفعل ذلك بقراءة الامتدادات داخل الشهادة.
ثلاثة فحوص يسهل خلطها في ذهنك
يعيش جذر الثقة في التوجيه ca. ينتمي فحص الدور إلى remote-cert-tls. وينتمي فحص الهوية إلى verify-x509-name، عندما يستخدمه ملف تعريف، أو إلى أي فحص اسم يضيفه النشر.
وهي تغطي أعطالًا مختلفة:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
يمكن أن يحتوي ملف تعريف على الثلاثة جميعًا ويظل ضعيفًا إذا كان CA مشتركًا على نطاق واسع جدًا، وهي مسألة إدارة مفاتيح لا مسألة توجيه.
ما الذي يقرأه فحص الدور
التوجيه ماكرو. يتمدد إلى شرط لاستخدام المفتاح وشرط لاستخدام المفتاح الموسع يسمّي دور خادم ويب TLS، لذا يجب أن تعلن شهادة النظير ذلك الغرض فعليًا. الشهادة الصادرة لمصادقة العميل لا تحقق ذلك، حتى عندما تكون الجهة نفسها قد وقّعت الاثنتين.
هذا مهم لأن CA المشترك شائع في النشرات الصغيرة. جهة واحدة توقّع كل عميل والخادم، وبدون فحص الدور يمكن لأي من تلك الشهادات أن تكمل جانب الخادم في المصافحة. الفحص لا يجعل ذلك السيناريو مستحيلًا، لكنه يزيل نسخته التافهة.
التوجيه غير متماثل بحكم التصميم: العملاء يحملون remote-cert-tls server، والخوادم تحمل remote-cert-tls client. بدّلهما ويفشل كل اتصال بخطأ دور يبدو كشهادة معطوبة.
تستخدم ملفات التعريف الأقدم أحيانًا ns-cert-type للغرض نفسه. تعتبر صفحات الدليل الحالية ذلك الخيار متجاوَزًا، لذا ملف التعريف الذي لا يزال يعتمد عليه يستحق الترحيل بدلًا من التنقيح.
لماذا يبدو تعطيله كإصلاح
عندما يفشل فحص الدور، يتوقف الاتصال بخطأ تحقق، والخطوة الواضحة هي حذف السطر. عندئذٍ يظهر الاتصال، وهذا يبدو كتقدم وهو في الحقيقة نمط الفشل الذي يوجد التوجيه لمنعه. أنت الآن تقبل نظيرًا لم تكن شهادته مخصصة لذلك الدور قط.
اقرأ الخطأ بدلًا من ذلك. إنه يسمّي الفحص الذي فشل، ويمكن فحص الشهادة على الجانب الآخر لمعرفة الامتدادات التي تحملها حقًا. دقيقتان من القراءة تحسمان ما إذا كان العطل في الإصدار أم في الإعداد. التخمين يكلّف بعد ظهر كامل وينتهي عادةً بملف تعريف مُضعَّف. شهادة خادم مجدَّدة فقدت استخدام المفتاح الموسع هي عطل حقيقي في التجديد، وليست سببًا لتخفيف العميل.
فحص الاسم توجيه منفصل
تلبية فحص الدور تعني أن النظير خادم ما موقَّع من جهتك. لا تقول شيئًا عن أي خادم، وهذا يهم عندما تصدر CA نفسها شهادات لعدة بوابات وتكون إحداها مخترقة أو معاد استخدامها.
verify-x509-name يقارن موضوع الشهادة بقيمة تهيئها، مع أنماط مطابقة للموضوع الدقيق أو البادئة أو حقل واحد. استخدم الحقل الذي يحدد البوابة فعليًا، وتوقّع تحديثه عن قصد عندما يتغير الاسم.
لا يستبدل أي من التوجيهين التعامل الجيد مع المفاتيح. إذا نُسخ ملف مفتاح العميل مع ملف التعريف هنا وهناك، فإن هوية النظير بقوة قائمة التوزيع فقط.
افحص الشهادة قبل تعديل ملف التعريف
اقرأ شهادة النظير وسجل العميل، بهذا الترتيب. تخبرك الشهادة بالأدوار التي تعلنها؛ ويخبرك السجل بالفحص الذي رفضها.
تطبع هذه الأوامر امتدادات الاستخدام وأسطر التحقق من اتصال مطوَّل:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyإذا أظهرت الامتدادات دور الخادم وما زال السجل يبلّغ عن فشل في الدور، فالأرجح أن ملف التعريف يشير إلى ملف شهادة خاطئ لا إلى شهادة سيئة. وإذا أظهرت الامتدادات مصادقة العميل فقط، فتوقف عن النظر إلى العميل وأصلح الإصدار. وفي كل الأحوال، أعد الفحص قبل أن تسمّي الاتصال سليمًا، لأن مصافحة ناجحة بعد إزالة التحقق تثبت أقل من الخطأ الذي حلّت محله.