جعلت Let's Encrypt انتهاء صلاحية الجذر حداً للمساءلة في الثقة بالشهادات

الملخص

• في 30 سبتمبر 2021، انتهت صلاحية شهادة الجذر DST Root CA X3 الخاصة بـ IdenTrust. حذرت Let's Encrypt من أن الأجهزة القديمة التي لا تثق في ISRG Root X1 ستبدأ في رؤية تحذيرات الشهادة، بينما كان للأجهزة القديمة التي تعمل بنظام Android مسار توقيع مشترك خاص للحفاظ على الوصول.
• لم يكن الفشل العملي انقطاعًا شاملاً في خدمة Let's Encrypt. بل كان حدث توافق عبر مخازن الثقة، وإصدارات OpenSSL، ولوحات تحكم الاستضافة، وسلاسل المشتركين، وأنظمة التشغيل، والأجهزة. شهد بعض المستخدمين والخدمات أخطاء شهادة بينما استمرت التطبيقات الحديثة بشكل طبيعي.
• تقع المساءلة عند حدود معينة. تحكمت Let's Encrypt في افتراضات سلسلة الإصدار والتوجيه العام. تحكم مسؤولو أنظمة التشغيل والمكتبات في سلوك مخازن الثقة وبناء المسار. تحكم مقدمو الاستضافة والمشتركون في السلاسل المنشورة، والتجديدات، وإشعارات العملاء. تحكم مالكو الخدمات العامة في التخطيط للاستمرارية للمواطنين الذين يستخدمون أجهزة قديمة أو بيئات مدارة.
• يدعم السجل درسًا عالي الثقة حول الاعتماد على طرف ثالث في الثقة. لا يدعم معاملة كل خدمة متأثرة بالإهمال، أو كل عميل بأنه عفا عليه الزمن بالاختيار، أو كل خطأ شهادة بأنه انقطاع من هيئة الشهادات.

سجل الأدلة وكيفية استخدامه

تستخدم هذه المقالة وثائق Let's Encrypt والتوجيه المجتمعي كدليل أساسي لخطة انتقال السلسلة والتحذيرات. وتستخدم مواد OpenSSL، وcPanel، وPlesk، وCertify The Web، وCatchpoint، وGravity Forms، وCA/B Forum، وRFC، وNIST، وENISA للسياق المتعلق بالتوافق، وعمليات المشتركين، وحوكمة الثقة العامة، واستمرارية العمل.

كان هذا حدثًا مجدولًا لكنه تصرف كحادث

لم يكن انتهاء صلاحية DST Root CA X3 مفاجأة بالمعنى التقويمي الضيق. شهادات الجذر لها تواريخ notBefore وnotAfter. نشرت Let's Encrypt توجيهات قبل 30 سبتمبر 2021. أوضحت وثائقها أن الأجهزة القديمة التي تفتقر إلى ISRG Root X1 سترى تحذيرات، باستثناء مسار Android القديم المدعوم بتوقيع مشترك خاص. كان تاريخ انتهاء الصلاحية معروفًا. كانت خيارات السلسلة موثقة. كانت منتديات الدعم العامة نشطة قبل التاريخ وبعده.

ومع ذلك، يمكن للأحداث المجدولة أن تتحول إلى حوادث عندما يكون رسم الاعتماد أكبر من مالك التقويم. يمكن لهيئة الشهادات أن تعلم أن جذرًا ما سينتهي صلاحيته. لا تستطيع تحديث كل جهاز مضمن، أو صورة مؤسسة، أو توزيعة لينكس قديمة، أو مخزن ثقة Java، أو نظام تشغيل محمول، أو لوحة استضافة، أو صورة حاوية أساسية، أو برنامج ثابت للجهاز، أو حزمة تطبيق خاصة. يمكن للمشترك تجديد شهادة. قد لا يزال يقدم سلسلة يبنيها عميل قديم بشكل غير صحيح. يمكن أن يحتوي العميل على مخزن ثقة يحتوي على ISRG Root X1. قد لا يزال يرفض سلسلة متوافقة مع Android لأن مكتبة بناء المسار تعامل مسار DST Root CA X3 المنتهي بشكل مختلف.

لهذا السبب يعتبر الحدث حالة مساءلة وليس مجرد ملاحظة توافق. يرى المستخدم رسالة ثنائية: الاتصال غير موثوق. خلف تلك الرسالة توجد شبكة من الثقة المفوضة. كانت شهادات Let's Encrypt موثوقة لأن مخازن الجذر، والتوقيعات المشتركة، وحوكمة CA/B Forum، وأتمتة ACME، وتكاملات الاستضافة، ومكتبات العميل جعلتها موثوقة. عندما انتهت صلاحية نقطة ارتكاز واحدة، كان لا بد من إعادة حساب الثقة عبر ملايين النقاط الطرفية.

يظهر السجل العام أن Let's Encrypt حاولت تقليل الضرر من خلال الحفاظ على توافق Android القديم. كان ذلك خيار وصولية دفاعيًا لأن قاعدة مثبتة كبيرة من أجهزة Android القديمة لا تزال موجودة. خلق نفس الخيار أو كشف مشكلات لبعض العملاء غير Android وإصدارات OpenSSL. درس المساءلة ليس أن الخيار كان خاطئًا بشكل واضح. بل هو أن مالك حدود الثقة يجب أن يشرح المفاضلة بوضوح كافٍ ليتمكن المشتركون ومشغلو الخدمات المعتمدة من اختيار وضع الاستمرارية الخاص بهم.

استمرارية القطاع العام تجعل أخطاء الشهادات أكثر من مجرد إزعاج للمتصفح

غالبًا ما تُصوَّر أخطاء الشهادات على أنها إزعاج: صفحة تحذير، أو استدعاء API مكسور، أو سكريبت فاشل، أو تذكرة دعم. بالنسبة للخدمات العامة، يمكن أن تكون المخاطر أكبر. قد يعتمد المواطنون على بوابات محمية بـ TLS للضرائب، والمواعيد الصحية، والمزايا، والتصاريح، والتعليم، والعدالة، والهوية، أو معلومات الطوارئ. إذا كانت مجموعة من الأجهزة لا تستطيع التحقق من سلسلة الشهادات، قد تصبح الخدمة غير قابلة للوصول للأشخاص الأقل قدرة على الترقية بسرعة.

لذلك، يجب على استمرارية القطاع العام أن تطرح سؤالًا مختلفًا عن موقع ويب استهلاكي. لا يكفي القول إن المتصفحات الحديثة تعمل بشكل جيد. أي أجهزة المواطنين، وأجهزة سطح المكتب المدارة، ومحطات المكتبات، وأكشاك الحكومة، والهواتف القديمة، والتقنيات المساعدة، وأجهزة البائعين، وتكاملات الوكالات موجودة في مجموعة المستخدمين؟ أي منها يثق في ISRG Root X1؟ أي منها يستخدم OpenSSL 1.0.2، أو مخازن ثقة Java، أو مخازن شهادات Windows، أو WebViews المحمولة، أو حزم الأجهزة المدارة؟ أي منها خارج سيطرة مالك الخدمة على التحديث المباشر؟ يختبر هجرة سلسلة الثقة تلك الافتراضات.

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

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

اختيار السلسلة هو قرار تحكم، وليس مجرد حقيقة تشفيرية

قد تبدو سلاسل الشهادات كقطع أثرية تقنية محايدة، لكن السلسلة المقدمة هي قرار تحكم. تظهر مواد Let's Encrypt لعام 2021 والنقاشات المجتمعية أن السلسلة الافتراضية والسلسلة البديلة حملت عواقب توافق مختلفة. ساعد المسار المتوافق مع Android أجهزة Android القديمة في الاستمرار في العمل. رفضت بعض إصدارات OpenSSL هذا المسار. احتاج مقدمو الاستضافة والمشتركون إلى معرفة أي سلسلة تقدمها خوادمهم وما إذا كانت هناك حاجة للتجديد أو تغييرات في التكوين.

شرح مشروع OpenSSL المشكلة بمصطلحات المكتبة. يمكن لـ OpenSSL 1.0.2 اعتبار الشهادات الصادرة عن Let's Encrypt على أنها ذات سلسلة ثقة منتهية عند تقديمها مع السلسلة الموصى بها التي تحتوي على وسيط ISRG Root X1 الموقع من قبل DST Root CA X3 المنتهي الصلاحية. ناقش توجيه مجتمع Let's Encrypt توافق عميل OpenSSL ولاحظ أن OpenSSL من 1.0.0 إلى 1.0.2 سترفض السلسلة المتوافقة مع Android بغض النظر عما إذا كان ISRG Root X1 موجودًا في مخزن الثقة. هذا فشل دقيق لمشغل غير متخصص.

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

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

أصبح مقدمو الاستضافة مترجمين للثقة العامة

معظم المشتركين لا يبنون سلاسل الشهادات يدويًا. يستخدمون لوحات الاستضافة، وعملاء ACME، ومضيفي WordPress المُدارين، وموازنات التحميل، ووحدات تحكم الدخول Kubernetes، والخوادم الوكيلة العكسية، وشبكات CDN، وواجهات الأجهزة، أو تكاملات المنصات. لذلك، تدفق حدث DST Root CA X3 عبر أنظمة مقدمي الاستضافة. تُظهر مناقشات cPanel وPlesk وCertify The Web ومجتمع Let's Encrypt الواقع التشغيلي: كان على المسؤولين تحديث مخازن الثقة، واختيار السلاسل، وتجديد الشهادات، وإزالة الجذور المنتهية، وإعادة تشغيل الخدمات، أو شرح سبب استمرار فشل العميل.

هذا الدور الترجماني مهم. يمكن لـ Let's Encrypt نشر شرح صحيح، لكن شركة صغيرة تستخدم لوحة استضافة لا تزال بحاجة إلى إجابة خاصة بالمنتج. أي ملف يجب تغييره؟ هل تقوم اللوحة بدمج مخزن CA الخاص بها؟ هل سيختار التجديد السلسلة الحديثة؟ هل يجب على الخادم حذف جذر منته؟ هل يحتاج العميل إلى إعادة التشغيل؟ هل سيتعطل مستخدمو Android إذا تم تحديد السلسلة البديلة؟ هذه ليست أسئلة PKI مجردة للمسؤول الذي يعمل تحت ضغط الموعد النهائي.

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

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

لم يوافق المستخدم على حدود الثقة

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

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

يدعم السجل العام حدودًا عادلة. حذرت Let's Encrypt من أن الأجهزة القديمة التي لا تثق في ISRG Root X1 سترى تحذيرات. حاولت أيضًا حماية مستخدمي Android القديمين. هذا لا يجعل Let's Encrypt مسؤولة عن كل عميل عفا عليه الزمن. لكنه يعني أن اتصالات هيئة الشهادات يجب أن تكون مفهومة لما وراء خبراء PKI لأن اختيار سلسلتها أثر على المستخدمين غير الخبراء.

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

الثقة الجذرية هي سلسلة توريد ذات حوكمة غير عادية

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

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

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

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

ما لا يثبته السجل

لا يثبت السجل العام انقطاعًا عالميًا. استمرت معظم المتصفحات والعملاء الحديثة في العمل. لا يثبت أن Let's Encrypt أصدرت شهادات بشكل خاطئ. لا يثبت أن كل مشغل خدمة متأثر كان مهملاً. لا يثبت أنه كان يجب دعم كل عميل قديم إلى الأبد. لا يثبت أن السلسلة المتوافقة مع Android كانت خطأً. الاستنتاج الأكثر أمانًا هو أن انتهاء صلاحية نقطة ارتكاز ثقة مخططة أنتج فشل توافق حقيقي في أجزاء من النظام البيئي.

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

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

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

اختبارات المساءلة العملية

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

الاختبار الثاني هو واقعية العميل. اختبر من المتصفحات الحالية، والمتصفحات القديمة ولكن المدعومة، وصور المؤسسات المدارة، وWebViews المحمولة، وعملاء سطر الأوامر، وبيئات تشغيل Java، والأجهزة المضمنة، وعوامل المراقبة. لا يجب أن يعتمد مشغل الخدمة العامة فقط على قفل المتصفح الأخضر من كمبيوتر محمول للمطور.

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

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

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

تحتاج الخدمات العامة إلى تقويم ثقة، وليس فقط روبوت تجديد شهادات

يجيب روبوت تجديد الشهادات على سؤال واحد ضيق: هل يمكن استبدال شهادة الورقة قبل انتهائها؟ أظهر حدث DST Root CA X3 أن السؤال الأوسع هو ما إذا كان كل طرف معتمد ذي صلة سيثق في المسار بعد تغيير النظام البيئي. لذلك، يجب على الخدمات العامة الحفاظ على تقويم ثقة يتضمن انتهاء صلاحية الجذور، وانتهاء صلاحية الوسطاء، وهجرات سلسلة هيئات الشهادات، وتغييرات برنامج جذر المتصفح، وتواريخ نهاية الدعم الرئيسية لأنظمة التشغيل، وإهمال المكتبات، وتغييرات شهادات المنصات المُدارة.

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

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

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

أتمتة المشترك خلقت المرونة والنقاط العمياء

غيرت Let's Encrypt اقتصاديات HTTPS من خلال جعل إصدار الشهادات وتجديدها آليًا على نطاق واسع. هذا إنجاز أمني كبير. تقلل الأتمتة من نسيان التجديدات، وتخفض حواجز التكلفة للمواقع الصغيرة، وتجعل النقل المشفر عاديًا بدلاً من خاص. لا يقوض حدث DST Root CA X3 هذا الإنجاز. يُظهر حد نوع واحد من الأتمتة. يمكن لروبوت التجديد الحفاظ على شهادة الورقة طازجة بينما لا تزال نقطة ارتكاز الثقة، أو التوقيع المشترك، أو الوسيط، أو مكتبة العميل، أو مخزن الجذر المحلي خارج سيطرة الروبوت.

تلك النقطة العمياء مهمة للمساءلة لأن العديد من المشغلين أصبحوا يعتبرون صحة الشهادات كإشارة لوحة تحكم ثنائية. إذا لم تكن الشهادة منتهية ويستجيب الخادم، تبدو الخدمة صحية. توافق السلسلة يطرح أسئلة أكثر. أي سلسلة تُقدم؟ أي العملاء يبنون أي مسار؟ أي الجذور موجودة في كل مخزن ثقة؟ هل يختار عميل ACME سلسلة بديلة؟ هل تحمل لوحة الاستضافة حزمة CA الخاصة بها؟ هل يتصرف عامل المراقبة مثل المستخدمين المتأثرين أو مثل متصفح حديث؟ يمكن للوحة التحكم التي تفحص فقط انتهاء صلاحية الشهادة أن تفوت فشل المستخدم الفعلي.

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

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

العملاء القدامى ليسوا مجرد ديون تقنية

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

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

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

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

يجب أن يكون لسجل انتهاء صلاحية الجذر حلقة تغذية راجعة بعد الحدث

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

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

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

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

تحتاج ثقة الطرف الثالث إلى تسميات حوادث بلغة واضحة

يُظهر حدث DST Root CA X3 أيضًا قيمة التسميات الدقيقة. قول "Let's Encrypt معطلة" كان سيكون خاطئًا للعديد من المستخدمين. قول "جميع الأجهزة القديمة معطلة" كان سيكون واسعًا جدًا. قول "بعض العملاء لا يستطيعون بناء مسار موثوق بعد انتهاء صلاحية DST Root CA X3" دقيق لكنه غامض. يحتاج الجمهور إلى لغة صحيحة وقابلة للاستخدام.

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

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

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

يجب أن تُختبر حالات فشل السلسلة مع عملاء غير المتصفح

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

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

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

الخلاصة للمساءلة

يظهر حدث DST Root CA X3 من Let's Encrypt أن البنية التحتية للثقة يمكن أن تفشل جزئيًا ومحليًا وبشكل مربك. قد تكون شهادة الورقة صالحة. قد يكون الخادم قيد التشغيل. قد تكون هيئة الشهادات حذرت. قد لا يزال المستخدم يرى فشلًا صعبًا لأن الجذر، والتوقيع المشترك، ومخزن الثقة، ومكتبة التحقق لا تتوافق.

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

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