إضافة عميل VPN دون إعادة بناء CA: متى وكيف

تحتاج شهادة أخرى لحاسوب محمول آخر، لكن أول درس في نتائج البحث يبدأ بأمر يمحو دليل PKI. ذلك الأمر يخص الإعداد الأول لا التسجيل، وتشغيله يكلّفك الـCA وسجل الإصدارات وكل ملف عميل كان يثق بالمُصدر القديم. القرار أمامك أضيق: هل ما زال لدى مُصدرك حالة قابلة للاستخدام، وهل يناسب الجهاز الجديد سياسة التسجيل التي تتبعها؟ ثلاثة شروط تحسم الأمر، وواحد فقط منها يبرّر إعادة البناء.

ما الذي تدمّره إعادة البناء فعلاً

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

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

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

الشرط الأول: هل حالة المُصدر ما زالت متاحة؟

حدّد الدليل الذي يثق به الخادم فعلاً قبل أي قرار. قارن الشهادة التي يقدّمها الخادم كـCA مع تلك في دليل PKI بالبصمة، لا باسم الملف:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

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

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

الشرط الثاني: من يحتفظ بالمفتاح الخاص الجديد؟

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

مع Easy-RSA 3 على CA قائم، استيراد الطلب وتوقيعه أمران:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

اختر نوع الشهادة عن قصد. طلب يُوقَّع كشهادة خادم بدل شهادة عميل ينتج ملفاً يبدو سليماً ويرفضه النظير، ورسالة الخطأ نادراً ما تشرح السبب. وإذا وقّعت بـopenssl ca فالقرار نفسه في الامتدادات التي تمررها لا في القسم الافتراضي.

الشرط الثالث: هل يحتاج الخادم أكثر من شهادة؟

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

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

الإجراء التزايدي، ومتى تكون إعادة البناء صحيحة

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

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

يجب أن يُظهر سطر الغرض SSL client. أنهِ بتحديث نسخة CA الاحتياطية بعد الإصدار، لأن نسخة أُخذت قبل تسجيل الرقم التسلسلي الجديد تعيد حالة بلا الجهاز الذي أضفته.

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