تسجيل الدخول إلى فيسبوك تم تمييزه على أنه غير متوافق بواسطة فيسبوك بعد التغيير إلى نظام شهادات Let's Encrypt

منذ حوالي 30 سبتمبر 2021 (بحسب ما أستطيع تحديده)، موقعي يولد أخطاء في الشهادات:

اتصالك ليس خاصًا
تحذير أمني ‘NET::ERR_CERT_COMMON_NAME_INVALID’.

لم يستطع هذا الخادم إثبات أنه www.nzarchitecture.net.nz؛ فشهادته الأمنية صادرة عن nzarchitecture.net.nz. قد يكون هذا ناتجًا عن سوء تكوين أو عن متنصت يقطع اتصالك.

قد تكون هذه المشكلة مرتبطة بالتغييرات التي طُبّقت من قبل Let’s Encrypt في ذلك التاريخ.
تُثار المشكلة عند استخدام الرابط https://www.nzarchitecture.net.nz، لكنها لا تظهر عند استخدام https://nzarchitecture.net.nz.

تستمر المشكلة حتى بعد التحديث إلى الإصدار التجريبي 2.8.0 بيتا 7 وإجراء إعادة بناء كاملة.

ونتيجة لظهور رسالة الخطأ على صفحة الهبوط الخاصة بي، تم تصنيف الموقع على أنه لم يعد يستوفي متطلبات فيسبوك، مما أدى إلى تعطيل تسجيل الدخول عبر فيسبوك من قبل فيسبوك نفسه.

إعجاب واحد (1)

هذه مشكلة في فيسبوك ويجب عليهم إصلاحها.

الشهادة موثوقة بنسبة 100%.

إعجاب واحد (1)

يبدو ذلك مشابهاً لـ…
https://meta.discourse.org/t/configuring-google-login-for-discourse/15858/239

إعجاب واحد (1)

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

في الوقت نفسه، يرفض فيسبوك مراجعة المسألة حتى تختفي الخطأ.

في ملف الإعدادات الخاص بك

/var/discourse/containers/app.yml

ما هي القيمة المحددة لـ DISCOURSE_HOSTNAME:؟

إعجاب واحد (1)

إذا كان موقعك الفعلي تحت النطاق غير المضمّن بـ www، فيجب عليك تسجيل النطاق غير المضمّن بـ www في نظام فيسبوك. لا يمكن الخلط بينهما.

4 إعجابات

يُظهر ملف app.yml

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

حسناً، أفترض أن هذا منطقي، ولكن من وجهة نظر DNS، أحدهما بديل للآخر (أو هكذا كنت أعتقد)، وسيكون من الصعب إخبار المستخدم العادي بأنه لا يمكنه استخدام ‘www’، خاصة إذا كان يحتاج إلى تسجيل الدخول لرؤية أي تحذير في هذا الشأن…

إعجاب واحد (1)

إنه ليس حقًا “اسمًا مستعارًا” بل إعادة توجيه. وتحتاج إلى إعداد إعادة توجيه بشكل صحيح، وهو ما يشمل وجود شهادة صالحة للموقع الذي توجد فيه إعادة التوجيه.

على سبيل المثال، يقدم شركاؤنا في Communiteq خدمة لذلك على https://www.forcewww.com/

4 إعجابات

حتى وقت قريب، لم يكن هذا يمثل مشكلة - فلا تحذيرات من فيسبوك، ولا تحذيرات تتعلق بالشهادات الرقمية سواء مع www أو بدونها.

هل توجد طريقة للحصول على شهادة Let’s Encrypt المجانية الافتراضية لتغطية الخيارين؟ نحن حريصون على عدم تعقيد الأمور بشهادات إضافية لإدارتها وتكلفة إضافية.

هناك العديد من رسائل البريد الإلكتروني التي تحتوي على روابط للموقع تتضمن www.

بعبارة “المكان الذي توجد فيه إعادة التوجيه”، هل تقصد Digital Ocean في هذه الحالة؟ (مقدم الاستضافة الخاص بي، ومنه تتم إدارة إعدادات DNS)؟

يمكنك إضافة سطر أو سطرين إضافيين إلى ملف app.yml. وقد نجح هذا معي عندما كنت أواجه مشكلات:

4 إعجابات

شكرًا لك - يبدو ذلك واعدًا

في حالتي، إذا كان https://nzarchitecture.net هو النطاق الأساسي، فهل الأسطر الصحيحة للإضافة هي ما يلي؟

after_ssl:
- replace:
filename: “/etc/runit/1.d/letsencrypt”
from: /–keylength/
to: “-d www.nzarchitecture.net.nz --keylength”

وهل يجب علي إعادة بناء discourse لكي يفعّل هذا التغيير؟

المحتوى صحيح، لكن المسافة البادئة مهمة في ملف yml، لذا يجب تصحيحها:

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d www.nzarchitecture.net.nz --keylength"

ستحتاج إلى إعادة البناء ليصبح التغيير ساري المفعول.

تعديل: في الواقع، يبدو أن استخدام --keylength قد استُبدل بـ -k، لذا ستحتاج إلى التالي بدلاً من ذلك:
أعتذر، لقد قادتني عملية البحث على GitHub إلى نسخة مشتقة قديمة دون أن أنتبه. --keylength هو الصحيح.

5 إعجابات

رائع! شكرًا جزيلاً على مساعدتك يا @Simon_Manning والجميع - لقد نجح إعادة التوجيه عبر app.yml تمامًا.

إعجابَين (2)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.