التحقيق في حالات فشل اسم الشهادة مقابل نقطة نهاية SMTP المبلغ عنها والسياسة المطبقة، مع الحفاظ على هوية HTTPS لمضيف السياسة منفصلة.
تحديد الشهادة التي تم تقييمها
مراجع: RFC 8460 §4.3.1, RFC 8461 §3.3.
تعد شهادة المضيف غير المتطابقة فئة فشل تفاوض النقل في RFC 8460 . ابدأ بنوع السياسة، ومجال السياسة، واسم المضيف-mx، والاستلام-IP، وفترة إعداد التقارير. قد يصف التقرير خدمة SMTP ، بينما MTA-STS يستخدم استرداد السياسة اسم مضيف HTTPS منفصلاً. لا تثبت الشهادة الصالحة على mta-sts.example.com أن mx1.example.net يقدم هوية SMTP مناسبة. وعلى العكس من ذلك، لن يؤدي إصلاح شهادة موقع السياسة على الويب إلى إصلاح نقطة نهاية SMTP التي تقدم شهادة خاطئة.
تحقق من مطابقة السياسة وهوية الشهادة بشكل منفصل
مراجع: RFC 8461 §4.1, RFC 8461 §4.2, RFC 8461 §3.3.
بالنسبة إلى MTA-STS ، يجب أن يتطابق مضيف MX المحدد مع أنماط MX المسموح بها في السياسة ويجب أن تستوفي شهادة SMTP TLS عمليات التحقق من الهوية والثقة المطلوبة. لا يعد نمط MX الموجود في السياسة شهادة تم إصدارها لهذا المضيف. يتطلب RFC 8461 §4.2 معرف DNS مطابقًا في الاسم البديل لموضوع شهادة SMTP . كما وثائق التحقق من اسم مضيف OpenSSL يوضح أن مدقق اسم المضيف العام قد يقبل احتياطي الاسم الشائع؛ وهذا وحده لا يلبي متطلبات SAN هذه. تحقق من هدف MX الفعلي، وليس مجال البريد الإلكتروني المرئي للمستلم أو تسمية DNS العكسي للخادم. احتفظ بسلسلة السياسة التي تم الإبلاغ عنها لأنه لا يزال من الممكن أن يستخدم المرسل نسخة مخبأة غير منتهية الصلاحية. قارن التكوينات التاريخية والحالية قبل تحديد التغيير الذي تسبب في عدم التطابق.
قم بالتجول عبر مثال نقطة النهاية الخاطئة
في التكوين الاصطناعي، يحتوي example.com على MX mx1.example.net وسياسة STS تسمح بـ mx1.example.net . تقدم نقطة نهاية SMTP شهادة تكون شبكة DNS الوحيدة الخاصة بها هي web.example.net . نجحت مقارنة سياسة MX، لكن اسم المضيف الدقيق غير موجود في نموذج هوية الشهادة هذا، لذا فشل التحقق من الهوية الموضحة. يؤدي استبدال مجموعة SAN في التركيبة المحلية بـ mx1.example.net إلى تبسيط عملية التحقق من الاسم الدقيق عن عمد. لا تعد الأداة أداة التحقق من صحة X.509 كاملة ولا تطبق أحرف البدل أو السلسلة أو انتهاء الصلاحية أو DANE قواعد.
افحص كل طريق يمكنه تقديم شهادة
يمكن أن تنتج موازنات التحميل وعناوين IP البديلة ومضيفي MX الاحتياطيين حالات فشل متقطعة إذا كان بعض المستمعين فقط لديهم الشهادة المقصودة. اجمع السلسلة المقدمة الفعلية وهوية نقطة النهاية من خلال SMTP المعتمد STARTTLS الاختبارات. قارن المسار والطابع الزمني بسجلات النشر. لا تقم بتعطيل التحقق من صحة اسم المضيف لاستدعاء الاختبار بنجاح. تجنب اختبار منفذ HTTPS فقط أو عنوان واحد مفضل ثم تعميمه على جميع مسارات البريد الوارد. تحقق من عائلات العناوين التي تم نشرها وذات صلة بالمبلغ المتأثر.
قم بإصلاح الطبقة المسؤولة وأعد الفحص
مراجع: RFC 7672 §3.1.1, RFC 8460 §4.1.
قم بتثبيت الشهادة الصحيحة أو توجيه الإصلاح إلى مستمع TLS المقصود. إذا كان نمط سياسة MX خاطئًا بالفعل، فراجع هذا التغيير بشكل منفصل وفكر في ذاكرة التخزين المؤقت للمرسل. لا تقم بإضافة أذونات بدل واسعة النطاق لمجرد إسكات فشل غير مبرر. احتفظ بالأدلة السابقة واللاحقة، ثم قارن التقارير اللاحقة حسب فترة حدوثها بدلاً من وقت الوصول. تتطلب سياسة DANE تحليل المصادقة الخاص بالاستخدام: هوية DANE-EE ليست نفس نموذج التحقق من الاسم مثل MTA-STS . المثال العملي لهذه المقالة هو STS بشكل صريح ولا يستخدم أي مجال إنتاج أو شهادة مباشرة.
الاحتفاظ بالأدلة التاريخية والفحوصات الحالية
تم التقاط ملاحظات النقل أدناه في 7 نوفمبر 2026 وتم فحصها، وليس إعادة تشغيلها كاختبارات للشبكة، لهذه المراجعة. يتم تسجيل عمليات التحقق من النموذج غير المتصل بالإنترنت بشكل منفصل.
يوثق عداء الأدلة/tls_lab.py والنتيجة المؤرخة مصافحة SMTP STARTTLS محلية حقيقية. يثق عنصر التحكم الإيجابي في CA المعملي المؤقت ويتحقق من صحة mx1.example .test. تستخدم حالة name_mismatch شهادة لـ web.example .test وتفشل باستخدام رمز التحقق من الشهادة 62. تتضمن النتيجة ذات الطابع الزمني تبادل SMTP ورسالة التحقق الدقيقة وبصمة الشهادة SHA-256؛ يحتفظ public_lab_certificates.json بالورقة العامة للفحص. لا يتم استخدام تجاوز التحقق من الاسم. يوثق هذا الالتقاط المحتفظ به فشلًا متحكمًا في نقطة النهاية ولكن ليس أي مسار لاستلام الإنتاج. يتطلب مشغل النقل التاريخي لغة Python مع التشفير ومآخذ الاسترجاع. نتائجها هي أدلة مختبرية محدودة، وليست صحة الخدمة الحالية أو قابلية التشغيل البيني للإنتاج.
أساس المصدر الأساسي
التعريفات الميدانية وحدود التقارير تأتي من RFC 8460 ، تقارير SMTP TLS، القسمان 3 و4. عند مناقشة التحقق من صحة STS، استشر RFC 8461. وتتميز التوصيات التشغيلية عن متطلبات البروتوكول.