مرحباً،
أنا أستخدم التثبيت القياسي.
هذا ما قمت بتعديله في app.yml:
hooks:
## إضافة شهادة Let's Encrypt لاسم النطاق غير www و www
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
اسم المضيف لـ Discourse الخاص بك هو: www.example.com
حتى الآن، الإعداد يعمل ويتم تسليم الشهادة لـ example.com و www.example.com.
ولكن عندما أتحقق من معلمات SSL باستخدام SSLLabs، فإن رأس HSTS مفقود للنطاق www.example.com. بالنسبة لـ example.com، فإنه يعمل:
تأمين النقل الصارم (HSTS) نعم
max-age=31536000; includeSubdomains; preload
ويقول Hardenize (www.hardenize.com) ما يلي:
إعادة التوجيه من HTTP إلى HTTPS ليست إلى نفس المضيف
عند استخدام HSTS، يجب أن يعيد منفذ النص العادي التوجيه إلى متغير HTTPS لنفس اسم المضيف. يضمن هذا النهج تمكين HSTS على اسم المضيف هذا، حتى لو تم إرسال العميل لاحقًا إلى مكان آخر. إعادة التوجيه إلى مضيف آخر آمن فقط إذا كان لمضيف أب لديه HSTS مع تمكين includeSubDomains، ولكن هذا ليس هو الحال هنا.
نقطة البداية:
http://example.deإعادة التوجيه الحالي:
https://www.example.comإعادة التوجيه المتوقعة:
https://example.com
السياسة غير محملة مسبقًا
عندما يتم تحميل اسم المضيف مسبقًا، فهذا يعني أن المتصفحات تقوم بتضمين سياسة HSTS الخاصة بك وتطبيقها حتى على الطلب الأول المرسل إلى موقع الويب الخاص بك. يشير هذا الخادم إلى التحميل المسبق في سياسته، ولكن اسم النطاق غير محمل مسبقًا بالفعل. نصنف هذا كتحذير لأنه مشكلة شائعة لوضع الكلمة المفتاحية “preload” في السياسة على الرغم من أن البنية التحتية ليست جاهزة للتحميل المسبق. هذا خطير لأنه في هذا الموقف، يمكن لأي شخص تقديم اسم النطاق هذا للتحميل المسبق بمجرد زيارة
hstspreload.org. نوصي إما بتحميل هذا النطاق مسبقًا بنفسك - إذا كان جاهزًا - أو إزالة مؤشر التحميل المسبق من السياسة حتى يصبح جاهزًا.
أي أفكار لماذا لم يتم تعيين رأس HSTS للنطاق www.example.com؟