خطأ شهادة الويب في Access Server: إصلاح حزمة CA الفارغة

صفحة دخول ويب ترفض التحميل بينما يُحل DNS بشكل صحيح ليست عادة مشكلة DNS. إذا ذكر سجل الخدمة مسارًا فارغًا لحزمة الشهادات أو فشل تحليل PEM لشهادة الويب والمفتاح الخاص، فمستمع HTTPS لا يملك مادة صالحة، ولن يساعده أي قدر من تحليل الأسماء. الإصلاح يكمن في ثلاثة مفاتيح إعداد، ولا يتضمن إعادة إصدار أي شهادة عميل VPN.

إلى ماذا تشير المفاتيح الثلاثة فعليًا

تُوصف مجموعة شهادة الويب المخصصة بالمفاتيح cs.cert وcs.priv_key وcs.ca_bundle. كل منها يخزن مسارًا إلى ملف، والمفاتيح الثلاثة تُستهلك معًا من قبل خدمة الويب. شهادة بمفتاح خاطئ، أو ملف سلسلة هو في الحقيقة الشهادة الطرفية، يفشل كما يفشل الإعداد الفارغ: لا يستطيع المستمع بناء سلسلة يقبلها المتصفح.

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

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

لماذا يفشل ملف موجود في التحليل رغم ذلك

المحلل يقرأ الكتل الموسومة داخل الملف، لا اسم الملف. الملف .crt الذي يحتوي مفتاحًا خاصًا، أو سلسلة مكتوبة كتلة واحدة مدموجة حيث كانت شهادة واحدة متوقعة، أو ملفًا حُفظ بسطر أخير مبتور، كلها ستُرفض. يعرّف RFC 7468 تلك الوسوم المقروءة لسبب: فهي الشيء الوحيد الذي يخبر القارئ بنوع الكائن التالي.

افحص الكائنات لا الامتدادات. على مضيف Linux، يجيب openssl x509 -noout -subject -issuer -in server.pem وopenssl pkey -noout -check -in key.pem عن السؤالين المهمين، ومقارنة المعامل أو المفتاح العام لكليهما تثبت أنهما ينتميان معًا. أبقِ مخرجات المفتاح الخاص خارج تذاكر الدعم وسجلات المحادثة؛ الفحص يحتاج بصمة، لا المفتاح.

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

الرجوع إلى البديل عن قصد

تتضمن واجهة سطر أوامر Access Server فحص تحقق يأخذ المسارات الثلاثة كوسائط ويبلغ عما إذا كانت المجموعة صالحة. المسارات أدناه توضيحية؛ استبدلها بالمواقع المحمية على المضيف:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

تحقق من الاسم الذي يكتبه المستخدمون فعليًا

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

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

مسح قاعدة بيانات الإعداد بالكامل ليس إصلاحًا للشهادة. استهدف تلك المفاتيح الثلاثة، طبّق، وأكّد أن واجهة الويب تستجيب. الملفات الموقعة ذاتيًا تحت دليل web-ssl هي مورد البديل لا مساحة عمل: الكتابة فوقها أو إعادة توليدها قد تزيل المادة الوحيدة العاملة.

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

الانتعاش لا يكتمل إلا بعد تسجيل دخول ناجح

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

يمكن لـ Access Server 3.1 وما بعده تقديم شهادات ويب مختلفة لكل اسم مضيف SNI. إذا كان ذلك مُهيأ، فالمفاتيح الافتراضية ومدخلات اسم المضيف مجموعتان منفصلتان، وقد يُظهر الاختبار عبر عنوان IP شهادة مختلفة عن التي يحصل عليها المستخدمون. أصلح مجموعة الاسم الفاشل وتحقق منها، ثم أعد اختبار تسجيل الدخول قبل إغلاق الحادث.