LetsEncrypt working without www, not with www

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?


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

And then:


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.

1 Like

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.


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:

Then of course:

./var/discourse/launcher rebuild app

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

1 Like

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:

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.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.