I hope someone can offer some advice, I would be in your debt. I’ll explain the situation. I’ve set up Discourse many times on my domain, hostballs[.]com. Each time visiting www[.]hostballs[.]com will nicely redirect to hostballs[.]com, because the LetsEncrypt certificate covers both with and without www. This is what I’ve come to know as the default, standard behavior of Discourse with it’s LE implementation. Currently, my new Discourse install is setting up SSL for the non-www site (as is configured as the URL), but it isn’t covering www. This means anyone visiting www[.]hostballs[.]com will not be redirected, but instead see an SSL error. Given that I know the default behavior to vary from this, and that Discourse’s installation is far too controlled for me to just want to run to certbot and start doing it all manually (won’t that make updating regularly fun), I’m uncertain of the best path forward. While trying to resolve this I commented out the ssl and LE templates, as well as the LE email address, in app.yml. I then removed the letsencrypt and ssl directories from /shared/standalone. I rebuilt the site without SSL, then re-enabled those options in app.yml and rebuilt again to generate new SSL certs/configs. While this succeeded, it still did not correct the www issue. Has anyone else dealt with a similar situation and found a resolution?

Easiest fix for someone using their root domain and wanting www to be signed by LE for proper https redirect without overcomplicating it or using another web server to manage the redirect: Change this: issue_cert() { LE_WORKING_DIR=“${LETSENCRYPT_DIR}” $$ENV_LETSENCRYPT_DIR/acme.sh --issue $2 -d $$ENV_DISCOURSE_HOSTNAME --keylength $1 -w /var/www/discourse/public } To this: issue_cert() { LE_WORKING_DIR=“${LETSENCRYPT_DIR}” $$ENV_LETSENCRYPT_DIR/acme.sh --issue $2 -d $$ENV_DISCOURSE_HOSTNAME -d www.$$ENV_DISCOURSE_HOSTNAME --keylength $1 -w /var/www/discourse/public } In file: /var/discourse/templates/web.letsencrypt.ssl.template.yml Then of course: ./var/discourse/launcher rebuild app

Sure! This is a little extra work but straightforward and a very common use case. See: [image] Set up Let’s Encrypt with multiple domains / redirects Sysadmins NOTE: @pfaffman says: This page needs to be cleaned up. There is now a new ENV setting that will let you add more hostnames. In your app.yml under your DISCOURSE_HOSTNAME line (it can go many places but that one makes sense), add DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com and early reports suggest that you’ll get valid certs for those domains and that accessing https://domain.com will properly redirect you to your DISCOURSE_HOSTNAME without a certificate error. If you do that an… And then: [image] (Superseded) Redirect additional domain(s) to your Discourse instance Self-Hosting warning 2024-04-09 @pfaffman edited this to say that this is no longer necessary, as the current NGINX config in the standard install redirects everything to https://HOSTNAME. You can test this by entering your IP address and see that it gets redirected. If you want multiple domains pointed to your server, you probably want them to have valid https certificates. To do that, follow instructions at Set up Let’s Encrypt with multiple domains / redirects. So you want to redirect domain(s) to yo…

If the above advice is too intimidating you could also set up a simple DNS redirect. Most registrars offer this. Discourse can’t be published under multiple URLs, the root record (non www) and www ‘a’ record are separate addresses. Once you nominate an FQDN for your site any additional addresses need to be handled with a redirect.

If you don’t like either of the suggestions provided already, you can opt to use www.example.com and use http://forcewww.com/ to redirect to the www site.

Thank you friends. Let me go over some details that might help someone else in the future. This started because a user told me that visiting www didn’t work, it gave a certificate error. When directly visiting their https link they provided in the reporting thread, I met the same. In the past when using www I had not met the same, but had instead been redirected to the root domain without issue. This led me to the conclusion that my installation after a recent migration was somehow broken and not acting according to default characteristics of a new Discourse installation. So I installed a fresh copy of Discourse on a new domain to set out to prove that www worked by default when using the root domain. I went to the domain, then I edited the URL in my address bar and added “www.” to the front of it. It redirected to the root domain without issue, as I expected. Then, I thought to try one more thing. I manually typed “https://” before it. It then failed with the same certificate error. So what may have led me to assuming that signing for www was default behavior in Discourse’s LE implementation may in fact have been my browser defaulting to port 80 while hiding the http/https portion of the URL from my view as I rewrote the URL in the address bar. This is my best assessment of the situation at least.

Yes, anything which hits the IP of your server on port 80 will be redirected to the actual FQDN over HTTPS, www isn’t a special case.

That isn’t a solution, the changes will be eradicated whenever templates are updated and for that reason alone is inadvisable. If you want to modify files within the container use hooks in your app.yml

Aye, I’m not seeing a way to achieve it that doesn’t have the potential to be broken on updates. This just seems to be the plight of people who have dedicated domains for communities and don’t like unnecessary subdomains. Short of running another web server elsewhere, of course.

Guides already exist for modifying certificate enrolment if you use the search.

Right, I’m already seeing one attempt that was then halted by a file changing so it broke the way they were setting it up to change the file in app.yml: [image] Problem in installing Let's Encrypt SSL for www and non-www Self-hosting Similar situation here. I installed Discourse on example.com and had a CNAME DNS record for www.example.com. Now I went to https://check-your-website.server-daten.de and got a bad rating, because the SSL certificate was not valid for www.example.com and also http://www.example.com was forwarding to https://example.com. Steps I took: Replace CNAME record for www.example.com by A and AAAA records. Add www.example.com as an additional domain to app.yml following Redirect additional domain(s) t… Whether we’re editing a file directly or having app.yml edit it afterward, an update has the potential to change that file and break how you’re editing it regardless.

My point is that any change to that template will break it again. Only one change has broken the PUPS/hooks method in the last few years, the introduction of support for ECC.

LetsEncrypt working without www, not with www

Product Support

merefield (Robert) January 18, 2020, 9:02am 2

Sure! This is a little extra work but straightforward and a very common use case. See:

And then:

Topic		Replies	Views
Problem in installing Let's Encrypt SSL for www and non-www Self-hosting	10	4975	December 3, 2019
Non www to www without certificate error Self-hosting	13	2157	January 17, 2022
SSL working on root, but not on www Product Support	28	4710	December 30, 2021
About force www to non www Product Support	29	3096	January 6, 2019
Making 'www' work with Discourse Product Support	30	3028	May 15, 2020

LetsEncrypt working without www, not with www

Related topics