الخلاصة

  • يثبت نجاح DNS-01 أن حساباً محدداً في ACME يملك مفتاح حسابه الخاص، وأنه يستطيع إظهار الملخص المطلوب عند اسم التحقق الذي تراه جهة إصدار الشهادات. وقد يمنح تفويض CNAME أو NS هذه القدرة الضيقة لطرف لا يسيطر على أصل النطاق أو التطبيق أو العلاقة التجارية.
  • الطلب والتفويض ونطاق البدل العام وCSR والإصدار وحفظ المفتاح والنشر والرصد في CT والإبطال حالات منفصلة. حذف سجل TXT أو حساب المورّد لا ينهيها جميعاً.

خروج اكتمل في التطبيق وبقي في DNS

عطّلت المؤسسة حساب المورّد في موفّر الهوية، وحذفت سرّه من التكامل المستمر، وأنهت دوره في مخزن الشهادات. لم يظهر اتصال نشط في سجل التطبيقات. لكن المنطقة الأم كانت لا تزال توجّه _acme-challenge.example إلى منطقة تحقق يتحكم بها الطرف السابق.

هذا التفويض ليس زينة في ملف المنطقة. توضح Let's Encrypt أن محلّل DNS-01 لديها يستطيع اتباع CNAME أو NS إلى منطقة أخرى. لذلك يمكن لمن يحتفظ بمفتاح حساب ACME ويتحكم بالإجابة النهائية أن يتلقى تحدياً جديداً، ويحسب القيمة المطلوبة، وينجز طلب بدل عام من دون الوصول إلى خوادم الويب.

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

ما الذي يجمعه الملخص فعلاً

لا يتعامل RFC 8555 مع TXT بوصفه كلمة مرور ثابتة. يرسل خادم ACME رمزاً عشوائياً لا تقل إنتروبيته عن 128 بت. يضم العميل الرمز إلى مفتاح حسابه لتكوين key authorization، ثم يحسب SHA-256 وينشر الملخص بترميز base64url عند _acme-challenge.<المعرّف>.

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

يمثل كائن authorization قرار الخادم بالسماح لحساب ما بتمثيل معرّف. وللحالة valid وقت انتهاء، وقد تنقضي لاحقاً أو تُعطّل أو تُسحب. سجل التدقيق المفيد لا يكتفي بعبارة «تم التحقق من النطاق»، بل يربط الحساب والتفويض والمعرّف والطريقة ومشاهدة التحقق وفترة الصلاحية.

سطح صغير قد يحمل قدرة إصدار كاملة

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

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

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

البدل العام قرار نطاق لا نجمة في TXT

في طلب البدل العام يعيد RFC 8555 authorization لاسم الأساس بعد حذف *.، ويضع wildcard: true. يمكن إذن أن يبدو اسم التحقق مثل اختبار عادي لاسم الأساس بينما تمنح الشهادة الناتجة نطاقاً أوسع. يجب حفظ العلم مع الطلب وCSR بدلاً من استنتاج النطاق من تسمية TXT.

تصف Let's Encrypt DNS-01 باعتباره طريقتها لإصدار شهادات البدل العام. هذا وصف لسلوكها الحالي وليس قاعدة لكل خادم ACME. ويضيف RFC 9444 نموذجاً اختيارياً قد تسمح فيه سياسة الخادم بتفويض نطاق سلف لإصدار شهادة لنطاق فرعي. لا يجوز افتراض الدعم؛ المرجع هو معرّف authorization الذي أصدره الخادم فعلاً.

يضبط CSR الأسماء ولا يحدد صاحب الصلاحية

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

لذلك يجب فصل الطلب والتفويض وCSR والإصدار والتخزين والنشر وأول مصافحة TLS مرصودة. لكل حدث مالك وتوقيت ودليل.

يمكن لـ CAA تقليص سطح إصدار آخر. يعرّف RFC 8657 معاملي accounturi وvalidationmethods الاختياريين في issue وissuewild. لا يعملان إلا إذا دعمت جهة الإصدار المحددة المعاني بصورة متسقة، ولا يستبدلان تحقق النطاق. ويحذر النص أيضاً من أن تفويض التحكم في نطاق فرعي قد يتجاوز قيود CAA. كتابة السياسة ليست دليلاً على إزالة تفويض التحقق.

تنظيف DNS ليس إبطالاً

يحذف TXT جواباً واحداً. ويزيل حذف CNAME أو NS مساراً واحداً بعد تقارب الذاكرات المؤقتة. وتعطيل authorization أو حساب ACME يغيّر حالة أخرى. لا يبطل أي منها بمفرده شهادة سبق إصدارها.

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

تجعل Certificate Transparency الإصدار غير المتوقع مرئياً وقابلاً للتدقيق، لكن SCT ليس تحقق الشهادة المعتاد، والإدراج في السجل لا يبطل الشهادة تلقائياً. الرصد يطلق الاستجابة؛ ولا يحل محل التحقيق والإبطال وإزالة النشر.

اختبر الحدود بفشل مقصود

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

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