الخلاصة

  • تتيح RFC 9773 لسلطة التصديق أن تقترح الفترة التي ينبغي للعميل أن يحاول فيها التجديد، وتتيح للطلب الجديد أن يسمّي الشهادة السابقة. ويبقى اختيار اللحظة العشوائية، وحفظ التراجع وخطة الاحتياط، وإتمام ACME، ونشر النتيجة تحت سلطة العميل المحلية.
  • إن suggestedWindow، وقبول replaces، وحالة الطلب valid، وتنزيل الشهادة، وإدخال CT، ووجود ملف على الخادم، ومشاهدة شهادة في مصافحة TLS جديدة، أدلة مختلفة. لا يحق لأي واحد منها أن يدّعي اكتمال المرحلة التالية.

كلمة واحدة تخفي ساعات كثيرة

تعرض لوحة التشغيل كلمة «مجددة». تبدو الكلمة واضحة لأنها تضغط وراءها ست ساعات لا تسير بالضرورة معاً.

تملك سلطة التصديق ساعة الفترة التي تفضّل استقبال العمل خلالها. ويملك العميل ساعة اللحظة التي يختارها داخل تلك الفترة. وتحدد Retry-After متى يعود العميل ليسأل عن المعلومات. وتحدد حالة الفشل متى يسمح بمحاولة جديدة. ويملك نظام النشر ساعة توزيع الشهادة وإعادة تحميل العمليات. وأخيراً، تكشف الخدمة العاملة في اتصال جديد أي شهادة تعرضها فعلاً.

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

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

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

هذا سيناريو تحليلي، لا وصف لحادثة منسوبة إلى سلطة بعينها. وهو يوضح السؤال الذي يجعل ARI قابلاً للإدارة: من يملك القرار في كل ساعة، وما الدليل الذي يسمح بالانتقال إلى الحالة التالية؟

الدليل ينشر موضع النصيحة لا أمر التنفيذ

يضيف خادم ACME الداعم لـARI عنوان renewalInfo إلى كائن الدليل. وعند طلب معلومات عن شهادة، يبني العميل معرّفاً قابلاً لإعادة الإنتاج: يشفّر keyIdentifier الموجود في Authority Key Identifier باستخدام base64url، ثم يضيف نقطة، ثم يشفّر بايتات الرقم التسلسلي بصيغة DER بالطريقة نفسها، مع حذف محارف الحشو الأخيرة. بعد ذلك يرسل طلب GET غير موثّق.

يسمح هذا البناء لتنفيذات مستقلة بأن تشير إلى الشهادة نفسها. لكنه لا يحوّل الاستجابة إلى أمر نشر.

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

تحتاج العمليات إلى إبقاء ثلاثة حدود واضحة.

النافذة ليست مدة صلاحية X.509، ولا تعدّل notBefore أو notAfter. وليست إجابة CRL أو OCSP عن الإلغاء. كما أن وجودها على الخادم لا يثبت أن العميل جلبها أو قبلها أو بدأ طلباً.

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

يختار العميل اللحظة ويحفظها

توصي RFC 9773 باختيار لحظة عشوائية موزعة بالتساوي داخل النافذة. إن كانت اللحظة قد مضت، يحاول العميل التجديد فوراً. وإن استطاع جدولة نفسه بدقة، ينتظرها. وإن كانت قبل استيقاظه العادي التالي، ينفذ الآن. وفي غير ذلك ينتظر موعد الاستعلام التالي عن RenewalInfo ويعيد التقييم.

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

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

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

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

Retry-After تضبط إعادة السؤال

في ARI، تعبّر Retry-After عن المدة المرغوبة قبل جلب RenewalInfo مرة أخرى، باعتبارها الحد الأدنى والأقصى المطلوبين مع حدود محلية معقولة، ومع أولوية التراجع عند الأخطاء.

إنها لا تحدد وقت إنشاء طلب الشهادة.

حين تصل القيمة Retry-After: 21600، يعرف العميل أن عليه تحديث المعلومات بعد نحو ست ساعات. وتظل اللحظة التي اختارها داخل النافذة حقيقة منفصلة. خلط الاثنين يمنع التمييز بين انتظار مقصود وبين نصيحة قديمة لم تُحدّث.

تعد مهلة الاتصال ومهلة الطلب واستجابات 5xx أخطاء مؤقتة، ويعالجها العميل بتراجع أُسّي وعدد محدود من المحاولات. وعندما تنفد، أو عند خطأ طويل الأمد مثل غياب Retry-After أو فسادها، أو كائن غير صالح، أو فشل DNS، أو رفض الاتصال، أو خطأ غير 5xx، يعود بعد ست ساعات أو بعد قيمة محلية مماثلة.

توصي Let’s Encrypt عملياً بفحص ARI مرتين يومياً على الأقل لكل شهادة، مع إبقاء قاعدة احتياطية تعتمد على مدة الصلاحية المتبقية. هذه إرشادات تشغيلية لسلطة بعينها، لا ثابت عالمي في RFC 9773. وينبغي للسجل أن يوضح ما أتى من البروتوكول، وما أتى من سياسة السلطة، وما اختاره المشغّل.

replaces تنشئ نسباً في الإصدار

يضيف ARI الحقل الاختياري replaces إلى طلب ACME. يستخدم معرّف الشهادة نفسه، ويعلن أي شهادة سابقة يقصد الطلب الجديد أن يحل محلها.

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

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

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

حالة valid لا تثبت التثبيت

تظل RFC 8555 حاكمة للإصدار. ينشئ العميل طلباً، ويستوفي تفويض المُعرّفات عند الحاجة، ويرسل CSR إلى عنوان finalize، وينتظر المعالجة، ثم ينزّل الشهادة من العنوان المضاف إلى الطلب.

تعني ready أن متطلبات الخادم مستوفاة وأنه ينتظر الإنهاء. وتعني processing أن الإصدار جارٍ. وتعني valid أن سلطة التصديق أصدرت الشهادة وأتاحت عنوانها. ويثبت التنزيل الناجح وصول البايتات إلى العميل.

ولا واحدة من هذه الحالات تضع البايتات في الخدمة.

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

لذلك يحتاج النظام إلى انتقالات منفصلة:

  1. جلب RenewalInfo والتحقق منها؛
  2. اختيار اللحظة وحفظها؛
  3. إنشاء طلب يحمل نسب الشهادة السابقة؛
  4. إكمال التفويض والإنهاء؛
  5. تنزيل الشهادة وحساب بصمتها والتحقق من المفتاح؛
  6. إيصال الأثر إلى أهداف مسماة؛
  7. نجاح فحص الإعداد وإعادة التحميل؛
  8. عرض البصمة الجديدة في اتصال محلي جديد؛
  9. تأكيد المسارات الخارجية المقصودة؛
  10. سحب المادة القديمة بعد فترة استرداد محدودة.

لا يبسّط المتغير المنطقي «مجددة» هذه السلسلة؛ بل يخفي موقع الفشل.

يسجل CT الإصدار ولا يزور نقاط الخدمة

تصف RFC 9162 سجلات عامة لشهادات TLS الصادرة أو المشاهدة. يتيح Certificate Transparency تدقيق نشاط سلطات التصديق، واكتشاف إصدار غير متوقع، واختبار خاصية الإضافة في السجل.

يمثل إدخال CT دليلاً قوياً على الإصدار أو الإرسال إلى السجل، لكنه ليس دليل نشر.

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

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

مصافحة جديدة تقترب من الحقيقة التشغيلية

في TLS 1.3 مع المصادقة بالشهادة، يرسل الخادم سلسلته في رسالة Certificate، ويثبت امتلاك المفتاح في CertificateVerify، ويكمل السجل الموثّق برسالة Finished.

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

يبقى الدليل محدوداً. لا يثبت مسار IPv4 المحدث حال IPv6. ولا يثبت موقع anycast واحد المواقع كلها. وقد تنهي أداة داخلية الاتصال قبل الطبقة العامة. وقد لا تعرض الجلسة المستأنفة التبادل الكامل المطلوب فحصه.

«في الزمن T عرضت النقطة E البصمة F عبر المسار P في مصافحة جديدة» جملة قابلة للتدقيق. أما «نُشرت عالمياً» فتحتاج إلى خطة مشاهدة تغطي هذا النطاق فعلاً.

سجل سببي لكل شهادة

ينبغي حفظ الحقائق منفصلة ومترابطة:

  • معرّف ARI ودليل ACME وآخر استعلام ناجح؛
  • بداية النافذة ونهايتها والشرح وبصمة الاستجابة وRetry-After؛
  • اللحظة المختارة والطريقة وانحراف الساعة ودقة الجدولة وإثبات الحفظ؛
  • حد الاحتياط وعدد الإخفاقات وآخر إخفاق وموعد المحاولة المسموح؛
  • الشهادة السابقة والحساب وعنوان الطلب ونتيجة replaces؛
  • أوقات التفويض والإنهاء والإصدار والتنزيل؛
  • البصمة والسلسلة وتطابق المفتاح ومكان الحراسة؛
  • الأهداف والفحوص وإعادة التحميل وحالة الرجوع؛
  • المصافحات الجديدة حسب المنطقة وعائلة العناوين وطبقة الإنهاء؛
  • سحب الشهادة السابقة والدليل الذي سمح بالسحب.

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

تبلغ سلطة التصديق عن النصيحة والإصدار. ويبلغ العميل عن الاختيار والطلب. ويبلغ نظام النشر عن الحراسة وإعادة التحميل. وتعرض نقطة النهاية شهادة. ويسجل المراقب مساراً. لا تحتاج أي طبقة إلى استعارة يقين الطبقة التالية.

النظام العامل يكمل الجملة

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

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

يبقى القرار المحلي في اللحظة والتراجع والخطة الاحتياطية. ويظهر التبنّي الطوعي في تطبيق العميل لـARI وطريقة دمجه. وتظهر أولوية النظام العامل في النهاية: تصبح الشهادة الجديدة حقيقة خدمة عندما تعرضها نقاط النهاية العاملة.

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

هذا الفصل لا يضعف الأتمتة. بل يجعل قياسها وإيقافها وعكسها ممكناً.

المصادر