الخلاصة

  • أتاح RFC 6844 لصاحب اسم النطاق أن يحدد جهات التصديق المخوّلة بإصدار الشهادات لذلك الاسم. وكانت قاعدة البحث الأولى تتبع CNAME أو DNAME ثم تصعد في شجرة الهدف؛ لذلك كان من الممكن أن تدخل سياسة CAA لدى مزود الاستضافة في فحص اسم أحد عملائه.
  • أبقى RFC 8659 حلّ الأسماء البديلة وفق DNS المعتاد، لكنه حصر الصعود إلى النطاقات الأم في الاسم الكامل الجاري فحصه. وبذلك رسم فصلاً أوضح بين سياسة العميل وشجرة أسماء مزود الاستضافة.

إجابة DNS لا تحسم إصدار الشهادة

لنفترض، على سبيل المثال فقط، أن www.client.example سجل CNAME يشير إلى tenant.platform.example. يمر اسم العميل عبر مساحة أسماء لخدمة استضافة مشتركة. وقبل إصدار شهادة، على جهة التصديق أن تجيب عن سؤال آخر: أي مجموعة سجلات CAA تنطبق على www.client.example؟

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

عرّف RFC 6844، الصادر في يناير 2013، سجل DNS من نوع 257 باسم Certification Authority Authorization. يستطيع صاحب اسم النطاق أن يذكر جهة تصديق واحدة أو أكثر يُسمح لها بالإصدار لذلك الاسم. وقبل الإصدار، على جهة التصديق الممتثلة أن تفحص مجموعة CAA ذات الصلة وترفض الطلب المخالف، إلا إذا انطبق استثناء منصوص عليه في سياسة الشهادات أو بيان ممارسات الجهة.

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

في 2013، كان البحث يعبر شجرتين

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

توضح أسماء افتراضية النتيجة. افترض أن www.client.example يشير إلى tenant.platform.example وأن مزود الاستضافة نشر CAA 0 issue "issuer.example" عند platform.example. كان الإجراء التكراري في RFC 6844 قد يتبع الاسم البديل ثم يصعد إلى platform.example فيجد السياسة. وهكذا كان سجل وضعه المزود في نطاقه الأم قد يدخل في بحث الإصدار للاسم العائد إلى العميل.

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

في 2019، بقي الصعود داخل شجرة الاسم المطلوب

استبدل RFC 8659، الصادر في نوفمبر 2019، RFC 6844 وعدّل خوارزمية المعالجة. ما زالت جهة التصديق تستعلم عن CAA للاسم الكامل المطلوب وفق آلية DNS العادية، التي قد تحل الأسماء البديلة. وإذا لم يُرجع الاستعلام مجموعة CAA، تصعد الخوارزمية في تسميات الاسم الجاري فحصه. لكنها لم تعد تصعد على نحو منفصل في شجرة كل هدف CNAME أو DNAME يظهر أثناء المعالجة.

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

يشرح RFC 8659 سبب التعديل عند مقارنته بالنص السابق: الصعود في شجرة الاسم وفي شجرة كل اسم بديل كان غير فعّال مع السلاسل الطويلة، وكان سيصعّب على مزودي الاستضافة وضع سياسة لنطاقاتهم الكاملة من دون فرض سياسات غير مرغوبة على العملاء. ضيّق النص الجديد السؤال: بعد حلّ الاسم بالطريقة العادية في DNS، ما مجموعة CAA التي تنطبق على هذا الاسم المطلوب، وما الذي تقوله أسماؤه الأم؟

قرار إصدار عند جهة التصديق، لا تحقق في المتصفح

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

كما أن سجل CAA لا يوثّق إجابة DNS بنفسه. يوصي RFC 8659 بشدة باستخدام DNSSEC مع CAA لكنه لا يجعله إلزامياً. وإذا حُظر الاستعلام أو وصل رد مشوّه أو عولج الرد الفارغ خطأً، فلن تملك جهة التصديق جواباً موثوقاً عن السياسة بعد. ويسرد فصل النشر في RFC هذه الأعطال لأن قاعدة التحكم لا تنفع إلا إذا استطاع المُصدِر استرجاعها وفهمها.

لـ CAA خصائص مختلفة أيضاً. تنطبق issue على الشهادات العادية، وتتعامل issuewild مع طلبات شهادات النجمة عند وجودها. ويمكن لقيمة المُصدِر الفارغة أن تطلب ألا تصدر أي جهة شهادة لذلك الاسم. تحدد هذه العلامات محتوى السياسة؛ أما تعديل 2019 فيحدد شجرة الأسماء التي ينبغي البحث فيها.

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

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

المصادر