مرحباً بالجميع،
تم التحديث مؤخراً إلى الإصدار 2.4.0.beta4 (1576b07a10)، ومنذ ذلك الحين لم تعد إحدى التطبيقات الخارجية قادرة على المصادقة مع واجهة برمجة تطبيقات Discourse.
يطرح التطبيق خطأً بسيطاً وهو:
تم إلغاء الطلب: تعذر إنشاء قناة آمنة SSL/TLS.
يستخدم التطبيق TLS1.2، هل لم يعد هذا الإصدار مدعوماً؟
هل لديكم أي أفكار حول التغييرات الأخيرة التي قد توفر عليّ ساعات عديدة من تصحيح التطبيق الآخر؟
تم تفعيل إصدارات TLS 1.2 و1.3، ويمكنك التحقق من ذلك بنفسك عبر SSL Server Test (Powered by Qualys SSL Labs)
شكرًا لك @Falco - تم التأكيد على أنه لا يزال موجودًا:
حسنًا، سأبدأ في عملية التصحيح، إذ يجب أن يكون هناك شيء آخر تغير في نظام Discourse لدينا مما يتسبب في تعطل تطبيقاتنا الخارجية، حيث يحدث هذا في كل من بيئتي التطوير والإنتاج لدينا.
سأرى ما يمكنني اكتشافه 
اتضح أن لدينا مشكلة مماثلة جداً لما ورد هنا:
تطبيقنا الخارجي القديم الذي يتصل بـ Discourse API يعمل على خادم Windows 2008 R2 قديم.
ولأسباب مجهولة، لم يتمكن خادم Windows وخادم Discourse من الاتفاق على مجموعة تشفير (cipher suite) بعد تثبيت تحديثات Discourse الأخيرة في وقت سابق من هذا الأسبوع. لا أعرف ما إذا كانت بعض مجموعات التشفير قد تم تعديلها خلال التحديث، أو إذا تزامنت هذه المشكلة مع تجديد شهادة LetsEncrypt في نفس الوقت 
على أي حال، بدلاً من تعديل إعدادات Discourse، تمكّنت من إضافة بضع مجموعات تشفير إلى خادم Windows يتفق عليها الطرفان، وذلك بمساعدة رابط SSL Labs الذي شاركه @Falco أعلاه 
واو، إنه قديم حقًا! تبقى أربعة أشهر فقط حتى نهاية دورة حياته. يبدو أن الوقت قد حان لاستبداله 
هل يمكن أن يكون هذا مرتبطًا بتغييرك يا @gerhard؟
أعتقد أن هذا سببه تغيير مجموعات التشفير أثناء الترقية إلى Debian. كنت أتوقع أن يؤدي إضافة شهادة المنحنى الإهليلجي إلى جعل هذا يعمل على جميع أنظمة Windows الأقدم، وليس فقط IE11. إذا لم أكن مخطئًا، فإن IE11 يستخدم مكتبة التشفير الخاصة بـ Windows…
