مطالبة مفتاح OpenVPN بعد OpenSSL 3: افحص المزوّد

لم يمسّ أحد الملف الشخصي، ومع ذلك يطلب العميل نفسه الآن عبارة مرور للمفتاح الخاص في كل مرة يبدأ فيها. وعندما يقع هذا التغيير خلال أيام من ترقية التوزيعة، فالترقية هي السبب المرجّح: فقد أعاد OpenSSL 3 تنظيم دعمه للخوارزميات، وقد يصبح مفتاح قرأته المكتبة القديمة بسهولة غير قابل للقراءة دون أن يتغيّر بايت واحد. نفّذ الفحوص بالترتيب، لأن اثنين منها يبدوان متطابقين من مجرد المطالبة.

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

تحقّق مما إذا كان المفتاح مشفّرًا

اقرأ السطر الأول من الملف ثم دع المكتبة تحلّله، لأن اسم الملف لا يثبت شيئًا. كتلة PEM تحمل الوسم ENCRYPTED PRIVATE KEY هي PKCS#8 مشفّرة، وكتلة RSA PRIVATE KEY الأقدم التي تحمل Proc-Type: 4,ENCRYPTED هي الصيغة التقليدية، وكلتاهما تتوقع عبارة مرور. أما كتلة PRIVATE KEY غير المشفّرة فلا ينبغي أن تطلب عبارة مرور على الإطلاق. شغّل التحليل بالحساب الذي يملك الملف، لأن مشكلة الأذونات تنتج خطأً مختلفًا وأقل إثارة بكثير.

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

تحقّق مما إذا كانت هذه النسخة قادرة على فك تشفيره

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

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

تحقّق من أضيق إصلاح متاح

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

لا تحذف عبارة المرور لتختفي المطالبة. فذلك يحوّل بيانات اعتماد محمية إلى ملف نصي صريح ويغيّر بهدوء مخاطر كل نسخة احتياطية ونسخة وحزمة دعم يظهر فيها. التمييز المهم هو بين مفتاح يحتاج عبارة مروره ومفتاح لا تستطيع هذه المكتبة فكّه.

افحص سياق الخدمة، ثم أعد الترميز

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

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

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

المطالبة عرض له ثلاثة أسباب على الأقل، وواحد منها فقط هو عبارة مرور مفقودة.