غرض الشهادة غير المدعوم: لماذا تفشل CA الوسيطة

يبدو غرض شهادة الخادم صحيحًا، والمفتاح متطابق، والتواريخ سليمة، ومع ذلك يفشل الاتصال بالخطأ unsupported certificate purpose. التفصيل الذي يحل الأمر يوجد عادةً في السطر نفسه الذي يحمل الخطأ: قيمة عمق وموضوع يسمّيان شهادة أعلى في السلسلة. يتم تشغيل اختبارين مختلفين، وواحد فقط منهما يخص شهادة الطرف. ومقارنتهما تفسّر لماذا لا يغيّر استبدال شهادة الخادم شيئًا.

أي شهادة رفضها المدقّق فعلاً

السلسلة ليست جسمًا واحدًا مكرّرًا ثلاث مرات. تحمل شهادة الطرف اسم الخادم ومفتاحه، وتربط الشهادات الوسيطة بها إلى جذر، ولكل واحدة منها فترة صلاحية وقيود واستخدامات خاصة بها. وعندما يذكر الخطأ قيمة عمق، فإن ذلك الرقم يحدّد موضعًا في السلسلة التي بناها المدقّق، وقد لا يكون الموضع الذي تتوقعه إذا أرسل الخادم سلسلة غير متوقعة.

اقرأ حقول الشهادة عند ذلك العمق لا الشهادة التي افترضت أنها السبب. اطلب الامتدادين اللذين يقيّدان الإصدار بدلًا من إخراج كل حقل، لأن الإجابة تكون دائمًا تقريبًا في أحدهما. مخرجات الامتدادات آمنة للمشاركة، أما المفاتيح الخاصة فلا تكون كذلك أبدًا.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

إذا كانت الشهادة المذكورة شهادة وسيطة يذكر استخدام مفتاحها الموسّع شيئًا لا علاقة له بمصادقة خادم TLS، فإن بقية الفشل تتبع ذلك ميكانيكيًا. لا يمكن استخدام السلسلة للغرض الذي طلبه OpenVPN.

غرض الطرف وسياسة السلسلة اختباران

يسأل اختبار الطرف سؤالًا ضيقًا: هل تسمح شهادة الطرف النهائي هذه بمصادقة الخادم لهذا الاسم؟ ويسأل اختبار السلسلة سؤالًا أوسع: هل يجوز لكل شهادة في المسار أن تؤدي ذلك الغرض؟ إن هيئة شهادات مسموح لها بإصدار شهادات العملاء فقط ستنجح في فحوص توقيعها الخاصة وستفشل مع ذلك في الاختبار الثاني، لأن المسار الذي تأذن به لا يتضمن الغرض الذي يحتاجه التطبيق. والاختباران يفشلان بالكلمات نفسها ولهما إصلاحان مختلفان تمامًا.

لهذا السبب يمكن لشهادة طرف صادرة حديثًا، صحيحة في كل حقل ظاهر، أن تفشل فورًا. ولهذا السبب أيضًا يكون الإصلاح عادةً في ملف تعريف هيئة الإصدار لا في إعدادات VPN.

غياب EKU ليس EKU مقيّدًا

يجعل RFC 5280 امتداد استخدام المفتاح الموسّع اختياريًا، ويكون مقيّدًا عند وجوده. لذلك فشهادة CA بدون الامتداد لم تقل «لا» لمصادقة الخادم، بينما الشهادة التي تسرد غرضًا غير ذي صلة فقط قالت شيئًا محددًا جدًا. والتعامل مع الحالتين على أنهما متكافئتان ينتج تشخيصًا خاطئًا، والأسوأ إصلاحًا خاطئًا. كما يفسّر هذا التمييز لماذا تتصرف هيئتان تبدوان متشابهتين في وحدة تحكم بشكل مختلف تمامًا داخل سلسلة.

سلوك المكتبات ليس موحّدًا هنا أيضًا. يصف وثيقة خيارات التحقق في OpenSSL معالجته الخاصة لفحوص الغرض على شهادات CA، وهذه المعالجة سياسة تنفيذ لا قاعدة تتبعها كل حزمة TLS بالطريقة نفسها. صف ما يفعله المدقّق لديك ثم تحقّق منه مقابل الإصدار الذي تشغّله فعليًا.

أعد إنتاج الفشل دون اتصال قبل إعادة الإصدار

يزيل التحقق دون اتصال التطبيق من المعادلة. إذا فشلت السلسلة بالطريقة نفسها تحت الغرض نفسه، فالشهادة هي المشكلة ولن يخفيها أي قدر من إعدادات الخادم. وإذا نجحت السلسلة دون اتصال بينما لا تزال الخدمة ترفض، فإن التطبيق يطلب غرضًا مختلفًا أو يستخدم سلسلة مختلفة عن التي اختبرتها.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain مهم لأنه يطبع المسار الذي بنته الأداة، وهو غالبًا ليس ترتيب الملفات الذي قدّمته. ذلك المخرجات أسرع طريقة لاكتشاف أن شهادة وسيطة ثانية تُسحب من مخزن ثقة، أو أن الخادم يرسل نسخة موقّعة تبادليًا لم تقصدها، أو أن علامة الغرض التي نسختها من درس تعليمي تخص دورًا مختلفًا عن الدور المخدوم.

أصلح سياسة الإصدار لا نداء التحقق

الإصلاح الدائم هو شهادة وسيطة صادرة بموجب سياسة تسمح بالأغراض التي يجب أن تخدمها، مع كتابة القيد ومراجعته. إضافة كل غرض إلى كل هيئة ليست سياسة؛ فهي تزيل القيد الذي جعل الامتداد ذا معنى في المقام الأول، وعادةً ما تبقى أطول من الحادثة التي دفعت إليها. وملاحظة قصيرة في ملف التعريف تصف الأدوار التي يجوز للهيئة أن تصدّق عليها تمنع إعادة الإصدار التالية من تكرار الجدال.

تعطيل التحقق هو الاختصار المغرٍ الآخر، وهو يحوّل مشكلة شهادة إلى مشكلة ثقة. أبقِ فحص الغرض في مكانه، وصحّح السلسلة، وأعد تشغيل التحقق دون اتصال نفسه لتأكيد أن المسار يخدم الدور المقصود قبل لمس الخدمة مرة أخرى.