اسم شائع واحد، شهادتان: قائمة سماح أم إلغاء؟

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

ابدأ بسياسة التسمية التي يستخدمها الخادم

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

اقرأ إعدادات الخادم ولاحظ مصدر الهوية المستخدم. username-as-common-name يجعل اسم المستخدم الموثّق هو الاسم الفعلي للاستعلامات الخاصة بالعميل. من دونه يُستخدم الاسم الشائع للموضوع من الشهادة. وأيًا كانت الإجابة، دوّنها قبل أن تمس أي قائمة سماح.

ينتج المساران مجموعة مختلفة من الأسماء المسموح بها للشهادة نفسها. التخمين هنا يعني تحرير الملف الخطأ والاستنتاج أن الضابط لا يعمل.

تحقق مما يقبل العميل فعلاً

ملف client-config-dir مطابق يوفّر خيارات لكل عميل؛ وهو بذاته ليس قاعدة قبول. القبول بالاسم يتطلب ccd-exclusive، الذي يرفض العملاء الذين ليس لهم ملف مطابق. وتفعيل ذلك على نشر حي يقطع كل من ليس لاسمه ملف، لذا أحصِ الملفات قبل أن تغيّر أي شيء.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

الإحصاء هو الفحص: قارن قائمة الدليل بالهويات التي تتوقع اتصالها.

ثم تأكد من أن كل اسم ملف يطابق الهوية الفعلية تمامًا، بما في ذلك حالة الأحرف والمسافات. ملف باسم office-laptop لا يفعل شيئًا لشهادة يقرأ موضوعها Office-Laptop. كما أن المسافات الزائدة تختفي من القائمة العادية، وهكذا يبقى ملف يبدو موجودًا غير مقروء.

تحقق من قائمة CRL التي تحمّلها البوابة

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

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

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

استبدل، ثم أثبت النتيجتين

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

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

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

ما لا يمكن لفحص الاسم فعله أبدًا

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

حيثما يلزم التحكم على مستوى الشهادة، استخدم آلية تسمّي الشهادة: إدخالات CRL، أو خطاف تحقق يفحص بصمة يحتفظ بها المشغّل. كلاهما يكلّف صيانة، وكلاهما صادق بشأن الكائن الذي يفحصه. دليل OpenVPN 2.6 يوثّق crl-verify والقبول الخاص بالعميل كخيارين منفصلين لهذا السبب.

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