خطأ شهادة سطح المكتب البعيد: اقرأ التحذير

ظهور تحذير «الشهادة» أو «الاتصال» عند محاولة الاتصال عن بُعد مزعج. رد الفعل — النقر على «قبول» والمتابعة — هو ما يعتمد عليه المهاجمون. يوضح هذا الدليل كيفية قراءة ذلك التحذير، وما الحقول المهمة، وتدفق قرار مختصر لتقرر ما إذا كان آمنًا الاتصال.

لماذا يظهر التحذير

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

• عدم تطابق اسم المضيف: Common Name (CN) أو Subject Alternative Name (SAN) في الشهادة لا يدرج المضيف الذي اتصلت به.
• انتهت صلاحية الشهادة: نافذة Not Before / Not After لا تتضمن الوقت الحالي.
• مُصدر ذاتي التوقيع أو غير معروف: لا يستطيع العميل بناء سلسلة وصولًا إلى مرجعية موثوقة.
• تم استبدال الشهادة أو تدويرها: الجهاز البعيد أعاد إنشاء الشهادة وتغيرت بصمتها.
• رجل في المنتصف (MitM): وكيل على المسار، بوابة مقيدة، أو مهاجم يعترض ويعرض شهادته الخاصة.
• إنهاء عند الريلاي: كثير من أدوات التحكم عن بعد تستخدم ريلاي في الوسط؛ عندما ينهي ذلك الريلاي TLS سترى شهادة الريلاي بدلًا من شهادة الجهاز البعيد.

ما الذي يجب قراءته في الشهادة — قائمة فحص عملية

عندما يظهر تحذير الشهادة افتح تفاصيل الشهادة وتحقق من الحقول التالية بالترتيب. لا تتجاوز مباشرة إلى «قبول».

1. الهوية (CN / SAN): هل يطابق Subject CN أو SAN المضيف الذي كنت تقصد الوصول إليه؟ في الأنظمة المعتمدة على الأجهزة قد ترى بدلًا من اسم مضيف معرف جهاز — قارن تلك القيمة بسجل الجرد.
2. المُصدر: هل المُصدر هي سلطة شهادات معروفة تثق بها، أو CA مؤسستك، أم مُصدر غير معروف/ذاتي التوقيع؟ سيعرض الريلاي المدار من قبل البائع عادة شهادته الخاصة؛ هذا ليس سيئًا بالضرورة لكن يجب أن تثق بمشغّل الريلاي.
3. تواريخ الصلاحية: هل الشهادة منتهية أو لم تصبح صالحة بعد؟ انحراف الساعة على أي طرف يمكن أن ينتج إيجابيات كاذبة؛ اختلاف صلاحية يمتد لأيام يحتاج تحقيقًا.
4. البصمة/طابع الشهادة: بصمة SHA‑256 (أو SHA‑1 كخيار احتياطي) تتيح لك التحقق من البايتات الدقيقة للشهادة عبر قناة خارجية.
5. السلسلة والإلغاء: هل السلسلة كاملة وصولًا إلى جذر موثوق؟ هل يستطيع العميل التحقق من OCSP/CRL؟ غياب وسيط غالبًا ما يسبب تحذيرات.
6. المفتاح وإصدار TLS: هل الشهادة تستخدم RSA 2048 أو ECDSA، وهل الاتصال يتفاوض على TLS 1.2 أو TLS 1.3 مع شيفرة حديثة؟ أحجام المفاتيح الضعيفة أو إصدارات TLS المتقادمة هي إشارات خطر.

كيفية جلب الشهادة والتحقق منها (أوامر وخطوات واجهة المستخدم)

طريقتان عمليتان لسحب الشهادة دون قبول التحذير في العميل: استخدم OpenSSL (عبر الأنظمة) أو افحص مربع تفاصيل الشهادة في العميل. الأمثلة أدناه تفترض أنه يمكنك الوصول إلى المضيف:المنفذ الذي يستخدمه العميل.

openssl s_client -connect host.example.com:PORT -servername host.example.com -showcerts

احفظ شهادة الخادم (الكتلة الأولى من الشهادات) في cert.pem، ثم فحصها:

openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -fingerprint -sha256

على Windows، إذا أظهر العميل زر تفاصيل الشهادة فانقر عليه وافتح "Details" → "Copy to File…" لتصدير الشهادة. يمكنك بعد ذلك تشغيل أمر openssl الثاني على ذلك الملف أو عرض الطابع في certmgr.msc.

إذا لم تتمكن من فتح مقبس إلى المضيف لأن الأداة تستخدم ريلاي، فسيعرض التحذير شهادة الريلاي. في هذه الحالة يجب أن تطلب من البائع أو المشغّل بصمة TLS للريلاي وتقارنها بالحوار — أو تقبل فقط إذا كنت تثق بمشغّل الريلاي (انظر ملاحظة Tenvo أدناه).

تدفق القرار: متى تتصل، متى تحظر، متى تستفسر

استخدم هذا تدفق قرار القصير بدلًا من النقر الأوتوماتيكي للقبول.

• إذا طابق CN/SAN المضيف أو معرف الجهاز وَطابقت بصمة SHA‑256 سجلًا موثوقًا لديك خارج القناة → اقبل واتصل.
• إذا كانت الشهادة منتهية لكن البصمة تطابق سجلًا موثوقًا وَتحققت أن ساعة الجهاز البعيد خاطئة (مشكلة NTP) → اقبل مؤقتًا لكن أصلح الانتهاء فورًا (دوّر الشهادة، صحح NTP) وسجّل الاستثناء.
• إذا لم يطابق CN/SAN، أو تغيّرت البصمة بشكل غير متوقع، أو كان المُصدر غير معروف ولا يمكنك التحقق من البصمة خارج القناة → لا تقبل. اتصل بمالك الجهاز أو بالمسؤول وتحقق من الشهادة عبر قناة موثوقة (هاتف، لوحة إدارة، قاعدة أصول).
• إذا أشار التحذير إلى شهادة ريلاي وتستخدم ريلاي طرف ثالث → تحقق ما إذا كنتم تستخدمون ريلاي مدارًا من البائع. إذا كان الأمر كذلك، أكد مشغّل الريلاي وبصمة شهادة الريلاي؛ تذكر أن الريلاي ينهي TLS لذا يجب أن تثق بمشغّل الريلاي لرؤية الجلسة.
• إذا رأيت تحذيرات شهادات غير متوقعة ومتكررة عبر عدة أجهزة مرة واحدة → اعتبرها احتمال MitM أو وكيل معطّل وصعِّد الموضوع فورًا.

فحوص عملية يمكنك إجراؤها بسرعة

• قارن البصمة باستخدام قناة ثانية: رسالة نصية، دردشة الشركة، أو نظام الجرد. لا تقبل بصمة مغيرة دون تحقق.
• تحقق من وقت نظام الجهاز البعيد (NTP) إذا كان الانتهاء هو الخطأ الوحيد. انحراف ساعة 24–48 ساعة شائع بعد فشل بطارية CMOS لكنه يجب إصلاحه.
• استخدم مسار وارد معروف جيدًا: اطلب من المستخدم البعيد فتح طرفية وتشغيل نفس أوامر OpenSSL أعلاه لتصدير بصمة الشهادة لتقارنها.
• افحص شبكتك: البوابات المقيدة والوكيلات الشفافة (شبكات Wi‑Fi بالفنادق، فحص HTTP المؤسسي) يمكن أن تعرض شهادات بديلة.
• سجل وراجِع: دوّن بصمة الشهادة وقرارك (قبول/رفض) في نظام التذاكر أو سجل الجلسات لاستخدام جنائي لاحق.

ما الأدوات والسياسات التي توفر وقت الفرق

لفِرَق تكنولوجيا المعلومات ضع سياسة وأدوات حتى تكون فحوص الشهادات سريعة ومتسقة:

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

تفاصيل Tenvo وقرار الاستضافة

عميلات Tenvo تستخدم TLS مع شهادة لكل جهاز. افتراضيًا توفر Tenvo ريلاي مدارًا متعدد المناطق لذا تعود الاتصالات إلى الريلاي عندما لا يكون مسار الند للند مباشرًا. هذا الريلاي المدار هو الإعداد الموصى به افتراضيًا: يزيل عنك تصحيح الشهادات المكثف، حفظ مفاتيح التشغيل وعمليات الفشل أحادي المنطقة. خطط Tenvo هي Free $0, Lite $2.99/mo and Pro $7.99/mo والريلاي يعمل في مناطق متعددة لتقليل نقاط الفشل المفردة.

حقيقة مهمة عن الريلايات: عندما تستخدم الجلسة ريلايًا، ينتهي TLS عند ذلك الريلاي. الاتصال المباشر ندّ لند يكون تشفيرًا من طرف إلى طرف بين الجهازين؛ جلسة تعتمد على ريلاي تعني أن من يدير الريلاي في وضع يتيح له رؤية الجلسة إذا اختار ذلك. لهذا السبب الريلايات المدارَة توفر بساطة تشغيلية لكنها تفرض قرار ثقة تشغيلي. الاستضافة الذاتية هي الخيار الصحيح فقط عندما تكون لديك متطلبات صريحة — مثل قاعدة امتثال تمنع بنية طرف ثالث، شبكة معزولة، أو قواعد صارمة لمكان تخزين البيانات. لمزيد من القراءة، راجع Self‑Hosted Remote Desktop: Why, How, and What Breaks وشرحنا Remote desktop encryption: what actually protects a session.

إذا كنت تقارن البدائل، لدى المنافسين مقايضات موضوعية — بعضهم يعرض مزيدًا من تفاصيل الشهادة في عملائه، وآخرون يجبرون استخدام ريلايات مُدارة. راجع صفحات مقارنة البائعين للتفاصيل: RustDesk comparison, TeamViewer comparison, AnyDesk comparison. واقرأ أيضًا مدخلنا الأمني في Is Remote Desktop Secure? An Honest Threat Model.

قائمة فحص مختصرة لاستكشاف الأخطاء يمكنك اتباعها في 5 دقائق

1. لا تنقر «قبول». افتح تفاصيل الشهادة.
2. دوّن CN/SAN وبصمة SHA‑256.
3. اتصل بمالك الجهاز أو تحقق من الجرد للتحقق من البصمة (هاتف أو دردشة الشركة).
4. إذا طابقت البصمة، تحقق من الانتهاء وNTP؛ إذا كان الانتهاء هو المشكلة الوحيدة، جدول تدوير الشهادة وصحح الساعات.
5. إذا لم تطابق البصمة أو لم تستطع التحقق منها، احظر الجلسة واصعد المشكلة.

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

إذا أردت العميل بسلوك شهادة وريلاي يمكنك تدقيقه، أو لديك احتياجات امتثال تجبر الاستضافة الذاتية، فاطلع على دليل الاستضافة الذاتية الكامل في Self‑Hosted Remote Desktop: Why, How, and What Breaks للاطلاع على المقايضات وتكاليف التشغيل.

هل تريد الاختبار محليًا؟ قم بتنزيل Tenvo وجرب اتصالًا مسيطرًا عليه حتى تتمكن من فحص مربع حوار الشهادة بنفسك: Download Tenvo.