مراقب دورة تجديد TLS في بيئة اختبار: مشاريع تخرج أمن الشبكات

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

قسّم دورة الشهادة إلى حالات

ابدأ بآلة حالات صغيرة: صالحة، تقترب من الانتهاء، طلب قيد التنفيذ، تحقق فاشل، أُصدرت شهادة اختبار، ثُبتت على خدمة المختبر، ثم تعذر التحقق بعد التثبيت. لا تسمّ الخطوة «تجديداً ناجحاً» قبل التأكد من أن الخادم التجريبي يقدم البصمة الجديدة. يُعرّف RFC 8555 بروتوكول ACME وموارده مثل الأمر والتفويض والتحدي؛ لوحة المشروع تختصر الأحداث اللازمة للفهم ولا تعيد تنفيذ المعيار.

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

استخدم staging للاختبارات

توصي Let's Encrypt ببيئة staging لاختبار إعداد عميل ACME، وهي منفصلة عن الإنتاج ولها حسابات وشهادات اختبار لا تُوثقها المتصفحات بالطريقة نفسها. ابدأ بها حتى لا تستهلك الفريق حدود الإصدار الحقيقية أو يخلط أحد شهادة الاختبار بمفتاح خدمة إنتاج. يمكن أن تستخدم نسخة مصغرة من الحالة ولا تحتاج إطلاق طلبات كثيرة؛ اختر حالات قليلة تكشف كل انتقال.

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

مثال بوقت متبقٍ وحد تنبيه

افترض شهادة مختبر تنتهي بعد 14 يوماً، وسياسة تعليمية تصدر تنبيهاً عند 21 يوماً، ثم تنبيه تصعيد عند 7 أيام. عند 14 يوماً يجب أن تكون الحالة «تحتاج تجديداً»، لكن لا يعني ذلك أن الإصدار فشل؛ ربما لم يحِن موعد التجديد الذي اختاره عميل ACME. اعرض وقت الانتهاء المحسوب من حقل NotAfter، والوقت المرجعي الذي استُخدم، وحد التنبيه في الإعداد.

إذا استلمت fixture أخرى شهادة جديدة تنتهي بعد 90 يوماً، يتحول حدث الإصدار إلى نتيجة مستقلة، ثم لا تتحول الحالة إلى «مستخدمة» حتى يقرأ عميل اختبار الشهادة من منفذ محلي ويقارن بصمتها. مدة 90 يوماً هنا قيمة توضيحية شائعة في إعدادات Let's Encrypt، وليست افتراضاً يصلح لكل جهة إصدار. الأفضل حساب الحد من البيانات الفعلية بدلاً من تثبيت رقم في الكود.

اختبارات القبول وحالات الفشل

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

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

ما الذي يسلمه فريق التخرج؟

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

حدود المشروع مهمة: staging لا يثبت أن بيئة الإنتاج مضبوطة، وقراءة شهادة على جهاز واحد لا تكشف اختلاف موازن تحميل أو خوادم متعددة. إن أضيف فحص عدة نقاط، يجب أن تسجل كل نقطة على حدة. وتوضح وثائق دليل تكامل ACME لدى Let's Encrypt عناوين بيئة الاختبار الحالية؛ لا تثبت رابط endpoint في التطبيق باعتباره صالحاً للأبد. يمكن للفريق قراءة مشروع فارق الإصدارات في تطبيق الويب لفهم الفرق بين نشر الملف ووصوله إلى المستخدم.

اختر حد التنبيه بحسب دورة العمل

لا يوجد رقم واحد يحدد متى يجب على كل فريق البدء بالتجديد. يمكن للمختبر أن يهيئ حدين مختلفين، مثلاً 21 يوماً للتنبيه المبكر و7 أيام للتصعيد، ثم يوضح كيف ظهرت الحالة على خط الزمن. وثائق Let's Encrypt توصي بنمط تجديد له هامش احتياطي، وتذكر أن فترة التجديد المقترحة قد تعتمد على عمر الشهادة وآلية ACME المتاحة. اربط أي توصية بمصدر وتاريخ مراجعة، ولا تعممها على جهات إصدار أخرى.

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