يمكنك التمييز بين انتهاء الصلاحية وفشل سلسلة الثقة، والحفاظ على نقطة النهاية المبلغ عنها والتحقق من صحة الشهادة التي تم تقديمها بالفعل بعد التجديد.
اقرأ فئة النتيجة بدقة
مراجع: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
الشهادة منتهية الصلاحية تعني أن المُبلغ لاحظ وجود شهادة منتهية الصلاحية. تغطي الشهادة غير الموثوقة عدة شروط، بما في ذلك المراجع المصدقة غير المعروفة والأخطاء المتسلسلة وقيود الاسم. قد يؤدي رمز سبب الفشل إلى تضييق نطاق التشخيص ولكنه نص مقدم من المراسل، وليس عقد محلل عالمي. لا تصنف كل تقرير شهادة غير موثوق به على أنه وسيط مفقود بدون دليل. ابدأ بسياق السياسة وقم بالإبلاغ عن نقطة نهاية الاستلام حتى لا يتم الخلط بين مشكلة شهادة SMTP وsts-webpki-invalid على MTA-STS مضيف سياسة HTTPS.
التحقق من الشهادة التي وصلت إلى المرسل
لا يثبت مدير الشهادات الذي يعرض شهادة مجددة أن كل مستمع SMTP يخدمها. قم بتسجيل الرقم التسلسلي أو بصمة الإصبع، وفاصل الصلاحية، والسلسلة والطابع الزمني للاختبار من نقطة النهاية المعتمدة الفعلية. قارن هذه القيم عبر مسارات الاستلام المتضمنة في التقارير. قد تؤدي العملية القديمة أو نسيان مضيف النسخ الاحتياطي أو النشر غير المكتمل لموازنة التحميل إلى ترك الشهادات القديمة نشطة. قم بمراجعة دقة الساعة عندما تبدو حدود الصلاحية غير متناسقة، ولكن لا تقم بتغيير الساعات أو المخازن الموثوقة لمجرد اجتياز اختبار فاشل.
إعادة إنشاء مشكلة تراكب التجديد
يحدد التمرين التركيبي شهادة قديمة صالحة حتى t=100 وشهادة جديدة صالحة من t=90 حتى t=200. عند t=110, يفشل المستمع الذي لا يزال يخدم الشهادة القديمة في التحقق من نافذة صلاحية النموذج، بينما يجتازها المستمع الذي يخدم الشهادة الجديدة. يؤدي هذا إلى إعادة إنتاج تمييز النشر دون إنشاء شهادة حقيقية. ولا يثبت الثقة المتسلسلة أو مطابقة الأسماء أو سلوك الإلغاء أو اصطلاحات حدود التنفيذ. هؤلاء بحاجة إلى أداة التحقق من صحة TLS الحقيقية وأدلة نقطة النهاية الخاضعة للرقابة.
التحقيق في الثقة دون تجاوزها
مراجع: RFC 8461 §4.2, RFC 7672 §3.1.1.
التقط الورقة وقدم السلسلة المتوسطة، ثم قارن سبب المراسل ببيئة الاختبار التي تمت صيانتها. قد لا يتم قبول المُصدر الموثوق به من قبل جهاز محلي واحد من قبل المرسل المتأثر. تعتبر الوسائط المفقودة والشهادة الموقعة ذاتيًا غير المتوقعة والقيود الخاصة بالسياسة بمثابة إصلاحات مختلفة. توثيق نموذج التحقق المحدد. SMTP DANE مع استخدام DANE-EE له دلالات ثقة مختلفة عن Web PKI، لذلك لا يمكن ببساطة تطبيق استنتاج على غرار STS حول سلطات التصديق العامة على كل TLSA تقرير.
أغلق الحلقة الخاصة بالنشر وإعداد التقارير
مراجع: RFC 8460 §4.1.
قم بتطبيق التجديد المعتمد أو تصحيح السلسلة على كل مستمع متأثر، والتحقق من سلوك إعادة التحميل والاحتفاظ بأدلة الشهادة المقدمة بعد التغيير. قارن التقارير التي تقع فترات مراقبتها بعد الإصلاح واحتسب تأخيرات التجميع. جدولة مراقبة التجديد مع مهلة زمنية كافية للملكية والطرح، ومراقبة ما إذا كانت الشهادة الجديدة قد تم نشرها بالفعل أم لا. لا تقم تلقائيًا بخفض سياسة النقل المفروضة لإخفاء حالات فشل الشهادة. يسجل هذا الدليل الاختبارات المعملية الخاضعة للرقابة فقط؛ ولا تقوم بتجديد شهادات الإنتاج أو تغيير مخازن الإنتاج الاستئمانية أو إثبات استرداد الإنتاج.
الاحتفاظ بالأدلة التاريخية والفحوصات الحالية
تم التقاط ملاحظات النقل أدناه في 7 نوفمبر 2026 وتم فحصها، وليس إعادة تشغيلها كاختبارات للشبكة، لهذه المراجعة. يتم تسجيل عمليات التحقق من النموذج غير المتصل بالإنترنت بشكل منفصل.
يتضمن التقاط الاسترجاع المحتفظ به شهادة موقعة من المرجع المصدق الموثوق به والذي انتهت صلاحيته قبل الاختبار؛ فشل مع رمز التحقق 10، انتهت صلاحية الشهادة. فشلت ورقة منفصلة موقعة ذاتيًا مع رمز التحقق 18، شهادة موقعة ذاتيًا. نجاح عنصر التحكم الصالح باستخدام نفس اسم المضيف المتوقع. يتم الاحتفاظ بأدلة المصافحة ذات الطابع الزمني والشهادات العامة، مما يسمح بفحص انتهاء الصلاحية وفشل الثقة بشكل منفصل. المفاتيح الخاصة مؤقتة ويتم إزالتها. يظل طرح تجديد الخدمة الفعلي والتحقق من نشر كل المستمعين خارج هذا التمرين المعملي. يتطلب مشغل النقل التاريخي لغة Python مع التشفير ومآخذ الاسترجاع. نتائجها هي أدلة مختبرية محدودة، وليست صحة الخدمة الحالية أو قابلية التشغيل البيني للإنتاج.
أساس المصدر الأساسي
التعريفات الميدانية وحدود التقارير تأتي من RFC 8460 ، تقارير SMTP TLS، القسمان 3 و4. عند مناقشة التحقق من صحة STS، استشر RFC 8461. وتتميز التوصيات التشغيلية عن متطلبات البروتوكول.