قبل أن تحوّله: مفتاح SSH مقابل شهادة OpenVPN

يفشل الاستيراد بخطأ في الشهادة، فيبدو التصرف البديهي كأنه تحويل. يدفع هذا الحدس الناس إلى مسار تتغيّر فيه امتدادات الملف ويبقى الرفض كما هو تمامًا. سطر ssh-ed25519 في authorized_keys وشهادة عميل OpenVPN كائنان مختلفان لبيانات الاعتماد، بمُصدِرين مختلفين وترميزين مختلفين ومساري إبطال مختلفين. ومرور هذه الفحوص بالترتيب يخبرك في غضون دقيقة إن كان التحويل قد يفيد أصلًا.

أي كائن بحوزتك فعلًا؟

ثمة خمسة أشياء يسمّيها الناس مفتاحًا، وواحد منها فقط هو ما يريده ملف TLS. المفتاح العام لـ SSH سطر نصي واحد يتكوّن من بادئة نوع وحمولة base64. وشهادة OpenSSH هي ذلك المفتاح زائد توقيع وprincipals وخيارات، ينتجها ssh-keygen وهو يعمل كجهة إصدار صغيرة خاصة به. أما شهادة X.509 فهي بنية مختلفة كليًا، تحمل موضوعًا ونافذة صلاحية وإضافات وتوقيعًا من جهة إصدار شهادات. والمفتاح الخاص هو النصف السري، والحزمة الصادرة عادة شهادة زائد سلسلتها زائد المفتاح الخاص في ملف واحد.

الفحص الأول يكلّف أمرًا واحدًا. وجّه openssl إلى الملف واطلب منه تحليل بنية الشهادة:

openssl x509 -in client.crt -noout -subject -issuer

إذا فشل ذلك بخطأ تعذّر التحميل أو خطأ PEM، فالملف ليس شهادة X.509 مهما كان الاسم الذي أطلقته عليه. إعادة التسمية لا تعيد كتابة ASN.1 في داخله، ولا يفعل ذلك تغليف سطر مفتاح عام بنص ترويسة PEM.

هل يطلب ملف الإعداد شهادة أصلًا؟

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

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

ما يمكن أن يفعله الترميز وما لا يمكنه

للمفاتيح الخاصة حاويات بديلة مشروعة. يمكن كتابة مفتاح RSA أو EC نفسه بصيغة PEM التقليدية أو بصيغة PKCS#8 أو داخل حزمة PKCS#12، وستحوّل الأدوات بينها بكل سرور. وللمفاتيح العامة قصة مشابهة: يستطيع ssh-keygen إخراج صيغة RFC 4716 لمفتاح SSH، ويفهم OpenSSH أيضًا صيغة الشهادة الخاصة به. كل ذلك تمثيل، والتمثيل ليس ثقة.

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

هذه هي الخطوة التي تفشل فيها معظم المحاولات بهدوء: صار الملف ينتهي بـ .crt، ويقرأه العميل دون اعتراض، ومع ذلك تتعطل المصافحة لأن القرين لا يستطيع بناء سلسلة إلى مُصدِر موثوق.

أين تدخل جهة إصدار الشهادات في الصورة

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

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

ماذا يكلفك إعادة استخدام مفتاح SSH

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

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