شهادة الطرف صالحة والسلسلة منتهية: اقرأ العمق

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

العمق يسمّي الشهادة التي فشلت

في تشخيص OpenSSL، العمق 0 هو الشهادة المستهدفة والعمق 1 هو المُصدر الذي وقّعها، مع أرقام أعلى تستمر نحو مرساة الثقة. لا يناقض انتهاء الصلاحية المُبلَّغ عنه عند العمق 1 وجود notAfter سارية على الطرف، لذا لن يفسّر فحص الشهادة المرئية مرة أخرى الخطأ أبدًا.

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

انتبه أيضًا للمنتجات التي لها أكثر من دور للشهادة. على OpenVPN Access Server، الشهادات التي تحمي واجهات الويب منفصلة عن تلك المستخدمة لاتصالات VPN، لذا فإن متصفحًا يفتح صفحة الإدارة لا يثبت شيئًا عن مسار النفق.

مدخلات الثقة ليست مرشحي السلسلة

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

تعطيل المسار والمخزن الافتراضيين باستخدام -no-CApath -no-CAstore يبقي الاختبار صادقًا: تعتمد النتيجة حينها على الملفات التي سمّيتها لا على ما يثق به الجهاز عرضًا. توثّق مرجع التحقق في OpenSSL هذه الخيارات والتشخيصات التي تنتجها.

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

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

ما يثبته الفحص وما يغفله

هذا فحص للمسار والغرض مقابل ملف ثقة وفّرته أنت. لفحص اسم HTTPS، أضف اسم المضيف المتوقع عبر الخيار المناسب؛ ولاتصال VPN، أبقِ فحوص الهوية المهيأة في العميل واستخدم مادة الثقة التي يقرأها ذلك العميل فعلاً.

ما يرسله الخادم هو مجموعة مرشحين، لا المسار الذي سيبني عليه عميلك في النهاية. الثقة المحلية وقواعد بناء المكتبة كلتاهما تشكّلان النتيجة، ولهذا قد تتحقق الاستجابة نفسها على جهاز وتفشل على آخر. قارن مخزن الثقة المُدار وطريقة تنفيذ TLS لدى العميل الفاشل مع عميل عامل قبل افتراض تقييم متطابق. الاختلاف هناك يفسّر الكثير من تقارير «هذا الحاسوب المحمول فقط يفشل».

لرؤية نافذة كل شهادة بدلاً من واحدة في كل مرة، اطبعها كمجموعة:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

يسرد الأمر الثاني الموضوعات والمُصدرين دون فك ترميز كل ملف يدويًا، وهكذا تكتشف شهادة وسيطة مضى تاريخها بينما لا يزال الطرف يبدو سليمًا.

أصلح المسار دون إضعاف التحقق

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

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

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