Summary

  • مسودة مجموعة HTTP لشهادات الخادم الثانوية، النسخة 03 حُدثت في 2 نوفمبر 2026 وما زالت Internet-Draft. تقترح إطار SERVER_CERTIFICATE ليبرهن خادم HTTP/2 أو HTTP/3، بعد إنشاء TLS، أنه يملك المفتاح الخاص لشهادة موقع إضافي.
  • يجب أن يعلن الطرفان دعمهما أولاً. يربط المُوثِّق المصدّر في RFC 9261 إثبات المفتاح بجلسة TLS القائمة؛ ثم يقرر العميل إن كانت الشهادة والخادم صالحين للموقع الثاني.
  • تسمي الفقرة 7.3 فخ المغادرة: نقل CNAME يوجه الاتصالات الجديدة إلى المزود البديل، بينما قد يستمر السابق في عرض الشهادة الثانوية عبر اتصالات فُتحت لمواقع أخرى. إنه عبء على المزود والعميل إغلاق هذا المسار الباقي.

لنفترض دار نشر تغير شركة الاستضافة. تغير CNAME وتصل الاتصالات الجديدة إلى البديل. لكن متصفح قارئ يحتفظ باتصال HTTP/2 لموقع آخر لدى الشركة السابقة. لا تزال الشركة تحمل شهادة موقع الناشر وترسل إثبات المفتاح عبر الاتصال المفتوح. إذا عَدّ المتصفح ذلك سلطة كافية، فقد يعود طلب لاحق للموقع المنقول إلى الطريق القديم. هذا اختبار تصوري للمشكلة التي تسميها المسودة.

الفائدة التقنية واضحة. يتيح HTTP/2 وHTTP/3 استخدام اتصال واحد لمواقع متعددة حين يملك الخادم سلطة خدمة كل منها. قد تشمل شهادة مصافحة TLS أسماء كثيرة، لكن شركة الاستضافة قد ترغب في شهادات مستقلة لكل عميل لتجديدها أو إبطالها منفردة. تبقي المسودة إدارة الشهادات منفصلة مع مشاركة وسيلة النقل. يبقى السؤال: ما الدليل على أن الموقع الثاني ينتمي إلى هذا الاتصال اليوم؟

اتصال واحد يكتسب هوية ثانية

تبدأ الآلية بموافقة صريحة. يرسل العميل والخادم كليهما SETTINGS_HTTP_SERVER_CERT_AUTH بقيمة 1؛ بدونهما لا يجوز تبادل الشهادة الإضافية. بعد ذلك يمكن للخادم إرسال SERVER_CERTIFICATE في أي وقت: على التدفق 0 في HTTP/2 أو تدفق التحكم في HTTP/3. يحمل الإطار مُوثِّقاً مصدّراً يثبت حيازة المفتاح الخاص للشهادة الإضافية داخل جلسة TLS القائمة. نسخة من ملف الشهادة وحدها لا تثبت صاحب المفتاح على هذا الاتصال.

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

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

ينتقل DNS ويبقى الاتصال

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

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

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

لا تقدم الملفات الرسمية عدد أنظمة مطبقة أو حادثة انتقال مقاسة. تجربة انتقال مضبوطة تجمع سجلات DNS والاتصالات وإطارات الشهادات ووجهات الطلبات تحدد النتيجة. العمل المطلوب واضح الآن: إغلاق مسار الشهادة الثانوية بعناية مماثلة لتغيير الاسم المستعار. تبديل اللافتة في الشارع لا يعطل مفتاح المبنى القديم.

مسودة HTTP · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336