Let's Encrypt: انتهاء صلاحية الجذر وحدود مساءلة الثقة

الملخص

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

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

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

الرقم	السجل العام	الاستخدام في هذا التحليل
1	Let's Encrypt، انتهاء صلاحية DST Root CA X3	المصدر الأساسي لانتهاء صلاحية 30 سبتمبر 2021، وتحذيرات الأجهزة القديمة، وانتقال ISRG Root X1، واستثناء التوقيع المتقاطع لنظام Android.
2	نسخة وثائق Let's Encrypt CA الخاصة بانتهاء صلاحية DST Root CA X3	نسخة ثانية مستضافة من Let’s Encrypt لتوجيه المشتركين وشرح انتهاء صلاحية الجذر.
3	Let's Encrypt، الوقوف على أقدامنا	خطة الانتقال واختيار سلسلة مزود الاستضافة والتحذير المبكر حول الانتقال من السلسلة الموقعة بشكل متقاطع إلى ISRG Root X1.
4	منتدى مجتمع Let's Encrypt، تغييرات سلسلة الإنتاج	توقيت سلسلة المشتركين العامة ومناقشة السلسلة الافتراضية وتوافق أجهزة Android القديمة والتحذيرات لغير Android.
5	مجتمع Let's Encrypt، تغييرات توافق عميل OpenSSL	مشكلة توافق OpenSSL 1.0.0 حتى 1.0.2 ومقايضة السلسلة الافتراضية.
6	مكتبة OpenSSL، انتهاء صلاحية شهادة جذر Let's Encrypt القديمة	شرح من جانب المكتبة لسبب اعتبار OpenSSL 1.0.2 للسلسلة منتهية الصلاحية.
7	سلسلة المساعدة في مجتمع Let's Encrypt	أسئلة الدعم التشغيلي واستكشاف أخطاء السلسلة وإصلاحها وأنماط معالجة المشتركين.
8	دعم cPanel، انتهاء صلاحية DST Root CA X3 و Let’s Encrypt	تأطير تأثير لوحة تحكم الاستضافة وتحذير مخزن ثقة العميل.
9	منتدى Plesk، انتهاء صلاحية شهادة جذر Let's Encrypt	دليل من مشغل الاستضافة على أن تغييرات مخزن الثقة كانت مهام تشغيلية.
10	Certify The Web، انتهاء صلاحية Let's Encrypt DST Root CA X3	إرشادات عميل إدارة الشهادات وتبديل السلسلة التلقائي المتوقع.
11	Catchpoint، المشكلات الناجمة عن انتهاء صلاحية Let's Encrypt DST Root CA X3	منظور الرصد المستقل وتحليل الانقطاع للتأثير العام.
12	Gravity Forms، العواقب الخفية لانتهاء صلاحية شهادة جذر Let's Encrypt	مثال على مشغل منتج نهائي لتطبيق وعواقب الدعم.
13	Let's Encrypt، تقصير سلسلة الثقة	تفكير لاحق بأن قاعدة تثبيت أجهزة Android القديمة شكلت قرارات دورة حياة التوقيع المتقاطع.
14	Let's Encrypt، نشر سلاسل إصدار جديدة	تبسيط السلسلة لاحقًا ودليل على أن التوقيع المتقاطع لـ DST Root CA X3 كان عنصرًا صريحًا في دورة الحياة.
15	المتطلبات الأساسية لمنتدى CA/Browser	حوكمة شهادات الثقة العامة وسياق الثقة الموزعة عبر البرمجيات.
16	RFC 5280	مفردات سلسلة الشهادات والـ CA والإبطال والطرف المعتمد.
17	NIST SP 800-52 Rev. 2	سياق نشر TLS وتكوين شهادة الخادم.
18	مشهد تهديدات الإدارة العامة الصادر عن ENISA 2024	سياق استمرارية الإدارة الرقمية في القطاع العام.

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

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

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

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

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

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

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

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

لا يتعلق عمل تهديدات الإدارة العامة لـ 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 وتحذيرات توافق. لا يمكن لمشرفي المكتبات تحديث كل عملية نشر، لكن يمكنهم توثيق السلوك وتوفير إصدارات مصححة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أحدثت أتمتة المشتركين كلاً من المرونة والنقاط العمياء

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يجب التمرن على إخفاقات السلسلة مع عملاء غير المتصفح

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

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

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

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

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

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

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