شهادة عميل موقعة ذاتيًا؟ خادم VPN ما زال يرفضها

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

الثقة تعيش على الخادم، لا في ملفك الشخصي

مصادقة الشهادات مقارنة. يقدّم العميل شهادة؛ وتتحقق البوابة مما إذا كانت موقعة من أحد المراجع في إعداداتها.

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

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

لماذا لا يمكن لشهادة موقعة ذاتيًا أن تحل محلها

الشهادة الموقعة ذاتيًا موقعة بمفتاحها الخاص. يتحقق التوقيع مقابل الملف نفسه، ما يجعلها متسقة مع نفسها وعديمة الفائدة كبيان اعتماد لبوابة شخص آخر.

البوابة لا تسأل هل الشهادة متسقة داخليًا. إنها تسأل هل وقّعها مصدر موثوق.

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

مسار طلب توقيع الشهادة يحفظ مفتاحك الخاص

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

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

الحزم تُستورد، لا تُثبَّت

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

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

أضف الفحوص التي ربما تخطاها المشغّل

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

يذهب verify-x509-name أبعد عندما يستطيع المشغّل تسمية الموضوع أو SAN المتوقع. كلاهما إضافتان صغيرتان إلى الملف، وكلاهما له ما يبرره. افحص ما استلمته قبل استيراده.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

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

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