LetsEncrypt working without www, not with www

[Jarland (Jarland Donnell)]

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?

[merefield (Robert)]

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

Set up Let’s Encrypt with multiple domains / redirects

This is to address the problem where you get certificate errors with any redirects or CNAME DNS entries which point to your actual installed Discourse (sub)domain. If you do not have https configured already (you do if you have done a standard install recently) see Setting up Let’s Encrypt as your first step. There are two patterns that need to be replaced, one ending in --keylength, and another ending in --fullchainpath (in the actual file, your original domain is before each of these switche…

And then:

Redirect additional domain(s) to your Discourse instance

2024-04-09 This guide is outdated according 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. Origina…

[Stephen]

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.

[pfaffman (Jay Pfaffman)]

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.

[Jarland (Jarland Donnell)]

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.

[Stephen]

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.

[Jarland (Jarland Donnell)]

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

[Stephen]

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

[Jarland (Jarland Donnell)]

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.

[Stephen]

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

[Jarland (Jarland Donnell)]

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:

Problem in installing Let's Encrypt SSL for www and non-www

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 single/multiple domain…

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.

[Stephen]

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.