التحقق من شهادات TLS واستكشاف أخطائها وإصلاحها على Cisco ESA

المقدمة

يصف هذا المستند كيفية إنشاء شهادات TLS وتكوينها واستكشاف أخطائها وإصلاحها على جهاز أمان البريد الإلكتروني Cisco Email Security Appliance (ESA).

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

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

معلومات أساسية

يتيح تطبيق TLS على ESA الخصوصية لإرسال رسائل البريد الإلكتروني من نقطة إلى نقطة من خلال التشفير. يسمح هذا التطبيق للمسؤول باستيراد شهادة ومفتاح خاص من خدمة المرجع المصدق (CA)، أو إستخدام شهادة موقعة ذاتيا.

يدعم Cisco AsyncOS لأمان البريد الإلكتروني امتداد STARTTLS إلى بروتوكول نقل البريد البسيط (SMTP) (SMTP الآمن عبر TLS).

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

نظرة عامة ومتطلبات وظيفية

يمكن أن يستخدم المسؤول شهادة على الجهاز لأي من هذه الأسباب:

• لتشفير محادثات SMTP مع MTAs الأخرى التي تستخدم TLS (كلا المحادثات الواردة والصادرة).
• لتمكين خدمة HTTPS على الجهاز للوصول إلى واجهة المستخدم الرسومية (GUI) عبر HTTPS.
• للاستخدام كشهادة عميل لبروتوكولات الوصول إلى الدليل خفيفة الوزن (LDAPs)، إذا كان خادم LDAP يتطلب شهادة عميل.
• للسماح بالاتصال الآمن بين الجهاز وجهاز شبكة تهديدات الحماية المتقدمة من البرامج الضارة (AMP) من Cisco.

يأتي ESA مهيئا مسبقا بشهادة توضيحية يمكن إستخدامها لإنشاء إتصالات TLS.

تحذير: وفي حين أن شهادة الإثبات كافية لإنشاء اتصال آمن ب TLS، كن على علم بأنها لا تستطيع توفير اتصال يمكن التحقق منه. توصي Cisco بالحصول على شهادة X.509 أو شهادة بريد إلكتروني محسن للخصوصية (PEM) من مرجع مصدق.

تكوين الشهادة وتعيينها

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

• نشر شهادة موقعة
• تعيين شهادة

التحقق من الصحة

التحقق من TLS ل HTTPS

1. قم بالوصول إلى واجهة المستخدم الرسومية (GUI): انتقل إلى جهاز ESA الخاص بك باستخدام عنوان HTTPS URL (على سبيل المثال، https://esa.example.com)

2. فتح تفاصيل الشهادة: انقر فوق أيقونة معلومات الموقع (عادة قفل) الموجودة على يسار عنوان URL في شريط عنوان المستعرض.

3. التحقق استنادا إلى المستعرض الخاص بك:

     أ. Google Chrome: انقر فوق رمز القفل >الاتصال آمن > الشهادة صالحة.

     ب. Microsoft Edge: انقر فوق رمز القفل > الاتصال آمن > رمز الشهادة (أعلى يمين القائمة المنبثقة).

     c. Mozilla Firefox: انقر فوق رمز القفل >الاتصال آمن > مزيد من المعلومات>عرض الشهادة.

4. تأكيد الصلاحية: مراجعة "فترة الصلاحية" أو "الحالة" في عارض الشهادة. إذا كانت الشهادة تظهر على أنها صالحة، يكون الاتصال آمنا ويتم التعرف على الشهادة بشكل صحيح من قبل المستعرض.

التحقق من TLS لتسليم البريد الإلكتروني أو إستلامه

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

اتبع هذه الخطوات لمراجعة حالة TLS عبر واجهة سطر الأوامر:

1. سجل الدخول إلى واجهة سطر الأوامر: قم بالوصول إلى الجهاز عبر بروتوكول SSH باستخدام بيانات الاعتماد الإدارية الخاصة بك.
2. قم بتشغيل الأمر GREP: أستخدم Grepuble لتصفية سجلات البريد للنشاط المرتبط ب TLS.
3. تحليل معرفات الاتصال: مراجعة الإخراج استنادا إلى نوع الاتصال:
   • ICID (معرف الاتصال الوارد): راجع هذه الإدخالات للتحقق من TLS للاتصالات التي يتم استقبالها على وحدة الإصغاء.
   • DCID (معرف اتصال التسليم): راجع هذه الإدخالات للتحقق من TLS للاتصالات التي يتم تسليمها إلى MTA للخطوة التالية.

ملاحظة: يمكنك البحث عن سلاسل معينة مثل "نجاح TLS" أو "فشل TLS" لتضييق النتائج.

مثال نجاح TLS عند تلقي البريد

(Machine esa.example.com)> grep "ICID.*TLS failed" mail_logs
Sat Feb 14 19:20:28 2026 Info: ICID 111396123 TLS failed: [Errno 0] Error
Sat Feb 14 19:20:28 2026 Info: ICID 111396456 TLS failed: ('SSL routines:tls_early_post_process_client_hello:no shared cipher')

مثال فشل TLS عند إستلام البريد

(Machine esa.example.com)> grep "ICID.*TLS success" mail_logs
Sat Feb 14 19:14:38 2026 Info: ICID 111395123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384
Sat Feb 14 19:14:41 2026 Info: ICID 111395456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

مثال نجاح TLS عند تسليم البريد

(Machine esa.example.com)> grep "DCID.*TLS success" mail_logs

Sat Feb 14 19:12:56 2026 Info: DCID 21966123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 the.cpq.host
Sat Feb 14 19:13:00 2026 Info: DCID 21966456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

مثال فشل TLS عند تسليم البريد

(Machine esa.example.com)> grep "DCID.*TLS failed" mail_logs

Sat Feb 14 19:58:43 2026 Info: DCID 21967123 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled
Sat Feb 14 20:58:44 2026 Info: DCID 21967456 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled

التحقق من TLS ل LDAP

على الرغم من أن سجلات ldap_debug لا تظهر سلسلة TLS معينة، يمكننا تحديد ما إذا كان TLS ناجحا أو فشل عن طريق فحص إستجابة LDAP والمنفذ (المنافذ) قيد الاستخدام. لاتصالات LDAP، يعني هذا عادة المنفذ 3269 ل Active Directory أو المنفذ 636 ل OpenLDAP.

مثال TLS ل LDAP

(Machine esa.example.com) (SERVICE)> tail ldap_debug

Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) to server LDAP (ldaps-esa.example.com:3269)
Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) lookup success, (ldaps-esa.example.com:3269) returned 0 results timestamp=1771989863.189580

ملاحظة: للحصول على تحليل أكثر تفصيلا لحركة مرور LDAP ونشاط TLS، نوصي بالتقاط حزم الشبكة على الأجهزة المضيفة والمنافذ ذات الصلة.

استكشاف الأخطاء وإصلاحها

يوضح هذا القسم كيفية أستكشاف أخطاء TLS الأساسية وإصلاحها على ESA.

التحقق من الشهادات الوسيطة

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

تمكين الإعلامات الخاصة بفشل اتصال TLS المطلوب

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

ملاحظة: هذا إعداد عمومي، لذلك لا يمكن تعيينه لكل مجال.

أكمل الخطوات التالية لتمكين تنبيهات اتصال TLS:

1. انتقل إلى سياسات البريد > عناصر التحكم في الوجهة.
2. انقر على تحرير الإعدادات العامة.
3. حدد خانة الاختيار إرسال تنبيه عند فشل اتصال TLS مطلوب.

تلميح: يمكنك أيضا تكوين هذا الإعداد باستخدام أمر واجهة سطر الأوامر destination > setup.

كما تقوم ESA بتسجيل المثيلات التي يلزم وجود TLS لها لمجال ما، ولكن تعذر إستخدامها في الجهاز mail_log. يحدث هذا عند استيفاء أي من هذه الشروط:

• لا يدعم MTA البعيد ESMTP (على سبيل المثال، لم يفهم الأمر EHLO من ESA).
• يدعم MTA البعيد ESMTP، ولكن الأمر STARTTLS لم يكن موجودا في قائمة الملحقات المعلن عنها في إستجابة EHLO.
• أعلن MTA البعيد عن ملحق STARTTLS، ولكنه استجاب مع خطأ عندما أرسل ESA الأمر STARTTLS.

أستكشاف الأخطاء وإصلاحها باستخدام أدوات جهة خارجية

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

يمكن إستخدام أدوات الجهات الخارجية مثل CheckTLS.com وSSL-Tools.net للتحقق من التسلسل المناسب للشهادة عند الاستلام. راجع وثائق كل أداة لفهم كيفية التحقق من الترخيص.

ملاحظة: في حالة إستخدام شهادة موقعة ذاتيا، يتوقع حدوث فشل.

قرار

إذا كانت شهادة CA الموقعة قيد الاستخدام وفشل TLS-Verify، فتحقق من مطابقة هذه العناصر:

• الاسم الشائع للشهادة
• اسم المضيف (في واجهة المستخدم الرسومية (GUI) > الشبكة > الواجهة)
• اسم مضيف سجل MX: هذا هو عمود MX Server في جدول TestReceiver.

معلومات ذات صلة

• جهاز أمان البريد الإلكتروني من Cisco - أدلة المستخدم النهائي