ca md too weak: إعادة إصدار الشهادة أم خفض المستوى؟

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

ما الذي يسمّيه الخطأ فعلًا

يرفع OpenSSL خطأ التحقّق هذا أثناء بناء السلسلة، عندما تحمل الشهادة التي تعمل كجهة إصدار ملخّص توقيع لم يعد مستوى أمان المكتبة يقبله. يُرفض MD5 في المستوى الافتراضي، ويُرفض SHA-1 بمجرد رفع المستوى. ملخّص الشهادة الطرفية أقل أهمية هنا من ملخّص الجهة المُصدِرة التي توقّعها. ويمكن للسياسة نفسها أن ترفض جذرًا كان عاديًا تمامًا يوم إصداره.

لهذا لا يفعل تعديل auth أو data-ciphers شيئًا لهذا الفشل. تلك الإعدادات تحكم كيف تُحمى الحزم بعد المصافحة، بينما الكائن المرفوض وثيقة هوية تُفحص قبل وجود النفق. يمكن لشهادة أن تكون مرتاحة داخل نافذة صلاحيتها ومع ذلك تحمل توقيعًا لن تقبله المكتبة.

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

الشرط الأول: هل الكائن المرفوض هو الجذر؟

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

ملفات CA المجمّعة تحتوي غالبًا على عدة كتل، فحدّد الكتلة التي تُحمَّل فعلًا بدلًا من افتراض أن الأولى هي المسؤولة. الأمر openssl x509 -in ca.pem -noout -subject -issuer -text يصف شهادة واحدة في كل مرة، ما يعني تقسيم الحزمة أولًا إن كانت تحتوي على أكثر. قارن خوارزمية التوقيع المطبوعة بالملخّص الذي تتوقعه من الحقبة التي أُنشئ فيها الجذر.

ورقة موقّعة بـ SHA-256 تحت جذر ضعيف تظل تفشل، لأن فحص السلسلة يمشي إلى الأعلى بالكامل. هذا الترتيب هو ما يجعل الشرط التالي مهمًا.

الشرط الثاني: هل تتحكم في الجهة المُصدِرة؟

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

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

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

الشرط الثالث: ماذا يقبل أيضًا خفض المستوى

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

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

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

القرار، مكتوبًا كقاعدة

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

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