شهادة SSL الخاصة بي غير صالحة لـ www.domain.com ولكنها صالحة لـ domain.com
كيف يمكنني جعلها آمنة مع www؟ لدي شهادة SSL المجانية التي تحصل عليها عند استضافة Discourse بنفسك.
لا يمكنك.\n\nLet’s Encrypt مجاني أيضًا، لذا 
نعم، أعرف أنها مجانية، ولكن ما هي طريقة لتشفير www؟
نظرًا لأنني وجهتها إلى domain.com ولكنها تظهر “هذا الموقع غير آمن” عند المرور عبر www
لأنها تم إنشاؤها فقط لـ apex، أو أنك تشير إليها بشكل خاطئ أينما كنت تحاول إنهاءها.
يقوم Discourse بإنشاء شهادة SSL عند التثبيت. وهي من Let’s Encrypt. لذلك ربما يجب أن تسأل من أي شركة قدمتها لك الآن.
لا أفهم تمامًا سبب الإزعاج.
لأنك عند زيارة www.mysite.com، فإنه يطالب برسالة من نوع “هذا الموقع غير آمن، هل ترغب في المتابعة”، ثم يعيد التوجيه إلى إصدار SSL (https). سأطلب من Lets Encrypt أي حلول.
يجب عليك إنشاؤه لـ www أيضًا.
إذا قمت بإنشائه يدويًا، فيجب عليك استخدام شيء مثل certbot certonly --nginx -d domain.com -d www.domain.com. بشكل أساسي، كل نطاق فرعي يحتاج إلى خاص به.
لا أعرف كيف هو الوضع الآن، لكن شهادات الأحرف البديلة (نفس الشيء للنطاق الأساسي وكل النطاقات الفرعية) لم تعمل بشكل جيد عند إنشائها باستخدام Lets Encrypt.
ولكن مرة أخرى. لست بحاجة إلى القلق بشأن ذلك، لأن Discourse يقوم بذلك نيابة عنك - إلا إذا كانت إعدادات DNS الخاصة بك خاطئة أو لسبب آخر عندما لا يمكن الوصول إلى منتداك.
عذرًا، أنا لا أفهم تمامًا، يبدو أن نظام أسماء النطاقات (DNS) يعمل بشكل جيد، إنه مجرد إعادة توجيه لعنوان URL.
www -\u003e https://domain.com
هذا الجزء يقول
لا يدعم www.domain.com اتصالاً آمنًا
أنت ترى هذا التحذير لأن هذا الموقع لا يدعم HTTPS
ولكن عند استخدام domain.com يكون الأمر جيدًا.
هل يجب أن أجرب certbot certonly --nginx -d domain.com -d www.domain.com؟
لا أعرف ما الذي يجب أن تجربه، ولا أعرف حتى ما الذي تحاول القيام به، وكيف وأين.
كل ما أحاول قوله هو:
- تحتاج إلى شهادات مختلفة لـ apex و www، أو أن مواقعك في خادم الويب تم تكوينها بشكل خاطئ
- لست بحاجة إلى فعل أي شيء لأن Discourse ينشئ شهادة SSL لك عند إعداد منتدى
هناك موضوع حول هذا:\n\nSet up Let’s Encrypt with multiple domains / redirects
4 إعجابات
شكرا لك.
after_ssl:
# tell letsencrypt what additional certs to get
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d site.com -d www.mysite.com --keylength"
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--fullchainpath/
to: "-d site.com -d www.mysite.com --fullchainpath"
إذًا، هل هذا سيجعل www يذهب إلى mysite.com؟ أم العكس؟
لا. إنها تعطيك شهادتين. واحدة لـ apex، وواحدة لـ www.
إعجاب واحد (1)
إذا كان اسم المضيف الخاص بك هو site.com، فأنت على حق. ويبدو أن هذا هو الحال.
يوصى بشكل عام بأن يكون موقعك على www.site.com وأن يقوم النطاق الأساسي بإعادة التوجيه إلى www. ما سأفعله هو تغيير اسم المضيف الخاص بك إلى www.site.com والقيام بذلك بالعكس.
أعتقد أنه يمنح شهادة واحدة صالحة لكليهما.
4 إعجابات
مرحباً، أنا أقوم بتحديث هذا الموضوع لأنني اعتقدت أنني أصلحته بالأمس، ولكن الآن عند الوصول إلى www.mysite.com ما زلت أحصل على إعادة توجيه غير SSL.
النقطة الأساسية لديها SSL، فقط ليس www.
على الرغم من أنني طبقت هذا في app.yml الخاص بي في hooks:
after_ssl:
# أخبر letsencrypt ما هي الشهادات الإضافية التي يجب الحصول عليها
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d mysite.com -d www.mysite.com --keylength"
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--fullchainpath/
to: "-d mysite.com -d www.mysite.com --fullchainpath"
هل تتبع التعليمات الموجودة في https://meta.discourse.org/t/set-up-let-s-encrypt-with-multiple-domains-redirects/56685؟
إذا قمت بإدخال www.mysite.com في القالب الموجود في المنشور الأصلي، فسيؤدي ذلك إلى إنشاء:
after_ssl:
# tell letsencrypt what additional certs to get
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d www.mysite.com --keylength"
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--fullchainpath/
to: "-d www.mysite.com --fullchainpath"
global: true
لذلك، أنت تفعل ذلك بشكل خاطئ.
آه، إذن هذا ليس مكتوبًا يدويًا.
after_ssl:
# أخبر letsencrypt بالشهادات الإضافية التي يجب الحصول عليها
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d =domain2= --keylength"
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--fullchainpath/
to: "-d =domain2= --fullchainpath"
global: true
إذن هل يجب علي القيام بذلك واستبدال domain2 بـ mysite.com، ثم إعادة بناء التطبيق؟
إذا أدخلت اسم النطاق الخاص بك في الحقل، فسيتم ملء =domain2= تلقائيًا باسم النطاق حتى تتمكن من نسخ/لصق هذه الكتلة.
نعم.
إعجاب واحد (1)
مرحباً، لقد قمت بهذا للتو، وللأسف كانت النتيجة نفسها. هذا ما فعلته ولكن مع نطاقي بدلاً من ذلك.
لا توجد مسافات بيضاء، تنسيق صحيح.
after_ssl:
# أخبر letsencrypt بالشهادات الإضافية التي يجب الحصول عليها
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d =mysite.com= --keylength"
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--fullchainpath/
to: "-d =mysite.com= --fullchainpath"
global: true
نظرًا لأنك لم تحل هذه المشكلة، فقد قمت بإلغاء تحديد المربع “تم الحل”.
إذا قمت بإعادة بناء كثيرة باستخدام المقطع الآخر، فقد تكون مقيدًا بمعدل الطلبات.
هناك احتمال أن يكون القالب قد تغير مرة أخرى وأن هذا لم يعد يعمل، لكنني أشك في ذلك.
حلول تحديد معدل الطلبات هي الانتظار لمدة أسبوع أو إضافة نطاق فرعي ثالث.
يمكنك الدخول إلى الحاوية وتشغيل أمر لطلب عنوان URL ومعرفة الخطأ، لكنني لا أستطيع تذكر ما هو. قد تتمكن من رؤية خطأ إذا نظرت إلى
docker logs app
إعجاب واحد (1)
لقد وجدتها!
لا يمكن الإصدار لـ \"=mysite.com=\": اسم النطاق يحتوي على حرف غير صالح\"
لذا، هل يجب التخلص من علامات = لأنها كانت للمتغير؟
هل استخدمت النموذج في الصفحة الأخرى كما اقترحت ووضعت اسم المضيف الخاص بك في الفراغ؟
إعجاب واحد (1)