لذا فقد وجدت أخيرًا الوقت للعمل على أدلة “إعداد Let’s Encrypt مع نطاقات متعددة” و"توجيه نطاق واحد/عدة نطاقات إلى مثيل Discourse الخاص بك".
لقد أضفت الكثير إلى ملف containers/app.yml أكثر مما أضفت أنت، ويبدو أن كل شيء يعمل بشكل صحيح تقريبًا.
يتم استضافة Discourse الخاص بي على النطاق الفرعي www، وكان هدفي توجيه طلبات http و https من النطاق الرئيسي (apex domain) إلى النطاق الفرعي www. وهذا يعمل الآن، ولكن إذا ذهبت إلى https://mydomain.com، فسيتم التوجيه، لكن Chrome يظهر التحذير التالي في وحدة التحكم:
Redirecting navigation example.com -> www.example.com because the server presented a certificate valid for www.example.com but not for example.com. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling
إليك الإضافات الخاصة بي في ملف app.yml:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /return 301 https.+/
to: |
return 301 https://$host$request_uri;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /gzip on;[^\}]+\}/m
to: |
gzip on;
add_header Strict-Transport-Security 'max-age=31536000'; # تذكر الشهادة لمدة عام واتصل تلقائيًا بـ HTTPS لهذا النطاق
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
هل يبدو هذا صحيحًا؟ إذا كان الأمر كذلك، فهل هناك حل لمشكلة عدم تطابق اسم الشهادة؟
تعديل: لدي سجلان من نوع A، أحدهما للنطاق الفرعي www والآخر يستخدم @ لالتقاط جميع الطلبات الموجهة إلى النطاق الرئيسي. كلاهما يشير إلى عنوان IP الخاص بـ Digital Ocean droplet الخاص بي. أفترض أن هذا صحيح أيضًا؟
شكرًا لك.