في الواقع، كانت مشكلة IPv6 و Let’s Encrypt غامضة للغاية.
عند إعادة بناء Discourse - عمل كل شيء بشكل صحيح - تم إصدار شهادة جديدة.
لكن Let’s Encrypt التلقائي لم يعمل - حصل على مهلة زمنية لأن الموقع لم يكن قابلاً للوصول عبر IPv6 (أثناء التشغيل) ليتحقق Let’s Encrypt من مجلد .well-known.
تحققنا أيضًا من تثبيت Docker Host ولم يكن يحتوي على موجهات ip6tables إلى الشبكة الداخلية لـ Docker كما كان الحال مع IPv4 - لكن في ip6tables كان كل شيء مسموحًا…
قمنا أيضًا بتفعيل IPv6 في إعدادات Docker Host وأعدنا تشغيل الخدمة - لكن ذلك لم يساعد أيضًا.
نعم، هذا ما اتبعناه؛ قمنا بتثبيت Docker يدويًا أولاً قبل تشغيل discourse-setup.
مرّ وقت طويل منذ أن قمنا بذلك (سنتان ونصف)، وقد عمل كل شيء بشكل جيد في البداية، لكن بعد عام، عند إضافة سجل AAAA لـ IPv6، توقفت التجديدات التلقائية عن العمل، واضطررنا إلى تشغيل discourse rebuild في كل مرة للحصول على شهادة SSL جديدة.
هل تتوفر لديك أي سجلات من وقت فشل التجديد التلقائي؟ ستكون مفيدة للغاية.
أيضًا، هل قمت بأي انحراف عن الدليل الرسمي؟ مثل استخدام وكيل عكسي إضافي، أو إجراء تعديلات يدوية على ملف app.yml، أو تكوين جدار الحماية على نظام المضيف، وما إلى ذلك؟
لا أريد أن يبدو الأمر كما لو أنني أشك في كلامك، ولكن نظرًا لوجود الآلاف من التثبيتات ذاتية الاستضافة التي نعلم أنها منتشرة، وكثير منها يستخدم IPv6، لو كانت تجديدات شهادات SSL تفشل للمواقع التي تستخدم IPv6 لكان من المتوقع أن نسمع العديد من الشكاوى.
هذا يعني عادةً أن سجل DNS من نوع AAAA كان معطلاً. وفقًا لـ
أفترض أن هذا كان هو الحال بالفعل.
وبما أننا نستضيف عدة مواقع على DigitalOcean بشكل صحيح باستخدام IPv6 و Let’s Encrypt، يبدو أن المشكلة ناتجة عن خطأ من المستخدم. يرجى فتح موضوع جديد إذا تمكنت من تقديم خطوات تكرار المشكلة.