جعل التجديد مهمة استمرارية الخدمة
تجديد شهادة HTTPS لـ MTA-STS يكتمل مضيف السياسة فقط عندما يتم تقديم الشهادة الصحيحة فعليًا عند نقطة النهاية المطلوبة ويمكن لعميل التحقق من الصحة استرداد السياسة. لا يثبت إشعار الإصدار الناجح النشر أو اكتمال سلسلة الثقة أو التوفر. قم بتنظيم العمل حول الخدمة قيد التشغيل بدلاً من ترتيب الشهادات.
يقترح هذا الدليل التحكم في التجديد ومراجعة الفشل الخيالية. ولا يقوم بإصدار شهادات أو فحص المفاتيح الخاصة أو تعديل الاستضافة أو الاتصال بمجال العميل. لا تزال الشهادة الأصلية وملاحظات HTTP مطلوبة. يجب أن يوافق المالكون على إجراء النشر والتراجع المعتمد قبل أن يلمس المشغل الخدمة.
قم بجرد سطحي الشهادة
تقوم شهادة مضيف السياسة بمصادقة اسم مثل mta-sts.example.com أثناء استرداد HTTPS. تقدم خوادم SMTP المتلقية شهادات منفصلة لأسماء مضيفات MX الخاصة بها. يمكن أن يكون لهذه الخدمات مالكون مختلفون وأنظمة تجديد وتواريخ انتهاء صلاحية مختلفة. تجديد أحدهما لا يؤدي إلى إصلاح الآخر، حتى عندما تتم إدارة كليهما بواسطة نفس مزود الاستضافة. RFC 8461 الأقسام 3.3 و4.2
قم بتسجيل اسم مضيف السياسة والفريق المسؤول ومنصة النشر وبصمة الشهادة العامة الحالية وفترة الصلاحية وآلية التجديد المقصودة. قم بتضمين كل عنوان أو طبقة خدمة يمكنها الإجابة على نقطة النهاية. تحدد فترة صلاحية الشهادة notBefore وnotAfter، بينما يعتمد التحقق من صحة المسار أيضًا على قيود الشهادة والثقة الأخرى. يبدو أن تاريخ انتهاء الصلاحية المستقبلي وحده لا يعد نتيجة تحقق ناجحة. RFC 5280 الأقسام 4.1.2.5 و6
التحقق من الهوية والسلسلة قبل النشر
يجب أن يقدم مضيف السياسة شهادة غير منتهية الصلاحية صالحة لهوية DNS المطلوبة والتسلسل إلى جذر موثوق به من قبل المرسل MTA. تفويض الاستضافة من خلال أ CNAME لا يجعل الشهادة لاسم مضيف الموفر كافية. احتفظ باسم مضيف السياسة الأصلي في اختبارات التحقق من الصحة وقم بتوثيق السلسلة العامة التي من المتوقع أن يرسلها الخادم. RFC 8461 الأقسام 3.3 و8.2
استخدم الأسماء البديلة لموضوع الشهادة عند تقييم هوية الخدمة المقصودة. RFC 9525 هي مواصفات هوية الخدمة العامة الحالية وهي RFC 6125 قديمة، والتي يستشهد بها RFC 8461 . اجعل قواعد معرف DNS الخاصة بالتطبيقات الخاصة بـ MTA-STS صريحة بدلاً من استبدال سلوك التطبيق غير ذي الصلة بصمت. الاسم الشائع الذي يمكن قراءته بواسطة الإنسان ليس سببًا للتنازل عن عدم تطابق اسم المضيف. RFC 9525 الأقسام 2 و 6
خطط لوقت كافٍ للتعافي بأمان
اختر موعدًا نهائيًا للتجديد الداخلي يترك وقتًا لفشل الإصدار وأخطاء النشر والتحقق. ويعتمد الهامش المناسب على عمر الشهادة والملكية التشغيلية؛ لم يتم تحديد عدد عالمي من الأيام هنا. تعيين شخص مسؤول وجهة اتصال احتياطية. تعد المهمة المجدولة بدون وجهة تنبيه أو مالك بمثابة تبعية لم يتم التحقق منها، وليست عملية تجديد كاملة.
الاحتفاظ بالتعامل مع الشهادات داخل نظام إدارة السرية المعتمد. يجب أن تحتوي حزمة الأدلة على تفاصيل الشهادة العامة ومخرجات التحقق من الصحة، وليس المفاتيح الخاصة أو بيانات اعتماد الحساب. حدد ما يمكن للمشغل التراجع عنه، وكيف سيتم التحقق من الصلاحية الحالية وأي حالات الفشل تتطلب التصعيد. إن استعادة شهادة منتهية الصلاحية لأنها كانت التكوين المعروف بالأمس لا تعد خطة استرداد مفيدة.
اختبر نقطة النهاية المنشورة بدلاً من ملف الشهادة
بعد النشر المصرح به، يجب أن يحدد الفحص المقترح اسم المضيف الدقيق والعنوان ووقت UTC والسلسلة المرصودة ونتيجة التحقق من صحة الاسم ونتيجة الثقة. في حالة وجود عقد خدمة متعددة، احتفظ بالنطاق المحدد بالفعل. لا يمكن للاختبار المحلي الناجح للمشغل أن يثبت أن كل مرسل خارجي يثق في نفس الجذر أو يصل إلى نفس العقدة. قم بتسجيل تلك الحدود بدلاً من تحويل ملاحظة واحدة إلى استعداد عالمي.
ثم تحقق من أن عنوان URL الأصلي المعروف ينتج HTTP 200 مباشرًا مع السياسة المقصودة. يمكن أن يؤدي عمل الشهادة عن طريق الخطأ إلى تغيير اختيار المضيف الظاهري أو التوجيه أو عناصر التحكم في الوصول إلى التطبيق. يحظر MTA-STS اتباع عمليات إعادة توجيه HTTP أثناء الاسترداد، لذا فإن نجاح المتصفح بعد إعادة التوجيه غير كافٍ. يعد اتصال TLS الصالح واستجابة HTTP القابلة للاستخدام من شروط القبول المميزة. RFC 8461 الأقسام 3.2-3.3
افحص النشر الجزئي الخيالي
خذ بعين الاعتبار example.com الخيالي، الذي يتم تقديم اسم مضيف سياسته بواسطة عقدتين طرفيتين. يحصل نظام التجديد على شهادة جديدة، لكن عقدة واحدة فقط تعيد تحميلها. ويستمر الآخر في تقديم شهادة منتهية الصلاحية. يتم اجتياز الاختبار الذي يصل إلى العقدة المحدثة؛ لا يمكن للمرسل الذي يصل إلى العقدة الثانية مصادقة السياسة. هذه الملاحظات مختلقة ولا تثبت سلوك أي مقدم خدمة حقيقي.
يقارن التحقيق المقترح بصمات الأصابع العامة وفترات الصلاحية في عقد الخدمة، متبوعة باسترجاع موثق على اسم المضيف الذي لم يتغير. لا يبدأ الأمر بتخفيف عمليات التحقق من الشهادات أو حذف سجل الاكتشاف. سيكمل مالك المعالجة عملية النشر المعتمدة ويتحقق من كلا العقدتين. لا تزال شهادات SMTP MX بحاجة إلى التحقق من صحتها لأن إصلاح مضيف السياسة لا يذكر شيئًا عن حالتها.
فهم حدود ذاكرة التخزين المؤقت أثناء انقطاع الخدمة
يجب على المرسل الداعم الذي لديه سياسة مخزنة مؤقتًا صالحة وغير منتهية الصلاحية الاستمرار في استخدامه إذا تعذر جلب السياسة المباشرة. يستمر المرسل الذي ليس لديه مثل هذه السياسة كما لو كان MTA-STS غائبًا بعد فشل الجلب. وبالتالي، يوفر عمر ذاكرة التخزين المؤقت فائدة محدودة للاستمرارية لبعض المرسلين، وليس الإذن بالسماح بانتهاء صلاحية شهادة HTTPS. يمكن للمرسلين المختلفين احتلال حالات مختلفة أثناء انقطاع الخدمة نفسه. RFC 8461 القسم 3.3
يحدد معرف الاكتشاف مثيل السياسة، وليس الرقم التسلسلي للشهادة. إذا تغيرت الشهادة فقط وظل نص السياسة متطابقًا، فلا تفترض أن معرفًا جديدًا مطلوبًا لجعل التجديد فعالاً. إذا تغيرت السياسة أيضًا، فاتبع ترتيب تحديث النص قبل المعرف وحساب السياسات المخزنة مؤقتًا. احتفظ بنشر الشهادة ومراجعة السياسة كتغييرات قابلة للمراجعة بشكل منفصل. RFC 8461 الأقسام 3.1 و8.1
احتفظ بالأدلة للتجديد القادم
احفظ سجل النشر المعتمد وتفاصيل الشهادة العامة قبل وبعد ونتائج الجلب المصادق عليها وأي شيء ذي صلة TLS-RPT الملاحظات. ينتمي فشل سياسة PKI على الويب إلى التحقيق في نقطة نهاية السياسة؛ يتعلق انتهاء صلاحية شهادة SMTP المبلغ عنها بالاتصال المتلقي. تحقق من الفئة التي تم الإبلاغ عنها بالفعل. RFC 8460 القسم 4.3
يتضمن سجل الأخطاء RFC 8461 الحالي تصحيحًا للأحرف الكبيرة تم الإبلاغ عنه حول شهادات MTA منتهية الصلاحية؛ ولا يسمح بالشهادات منتهية الصلاحية. لم يتم توفير أي دليل تجديد أو استضافة أصلي هنا. تظل البوابة التشغيلية النهائية عرضًا زمنيًا للخدمة المنشورة، ويراجعها مالكها. RFC 8461 أخطاء