Non www to www without certificate error

[Elmi (Ekmo)]

Hey community,

I have currently the following isse and I’d be really happy, if someone could assist me on finding the right approach.

1. I have installed discourse on an Ubuntu 21.10 server on Vultr
2. went with the default setup and created already a let’s encrypt certificate (for www.example.com) during the installation

My goal is that my forum is reachable only through www → www.example.com and not example.com

Current situation:
→ http://example.com correctly redirects (301) to https://www.example.com
→ http://www.example.com correctly redirects (301) to https://www.example.com
→ https://example.com throws a certifcate error and is not redirected to the correct https://www.example.com (the certificate was issued for www.example.com and not for example.com)

What is the best approach to make https://example.com redirect to https://www.example.com and how can I achieve my goal?

Best,
Elmi

[JammyDodger]

I followed this advice, and added a line to my app.yml:

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…

Though I don’t mind if people find me on the root domain or the www subdomain, so I haven’t tried it with redirects.

[michaeld (Michael - Communiteq)]

@JammyDodger

Though I don’t mind if people find me on the root domain or the www subdomain, so I haven’t tried it with redirects.

Beware for duplicate content in search engines.

[JammyDodger]

This is an area that I’m not that hot on. What would the recommended way be? I currently have an A record for both the domain and the www subdomain that resolve to my digital ocean droplet.

[michaeld (Michael - Communiteq)]

The easiest way is to use www.forcewww.com for that. (Disclaimer: that’s my own service)

[Elmi (Ekmo)]

Thanks a lot for your feedback @JammyDodger . I’ll give it a try even though it looks like it deals with a slightly different problem. But maybe it works.

It is best practice to have only one version of your site. Duplicate Content - Moz

[Jagster (Jakke Lehtonen)]

This kind redirecting is so trivial on any web-server and one googling reveals how to do it. Why is it different here?

[pfaffman (Jay Pfaffman)]

I’m pretty certain that if you request both certificates it will redirect as you desire. The forcewww.com solution is easier.

@Jagster

This kind redirecting is so trivial on any web-server and one googling reveals how to do it. Why is it different here?

Because it’s inside of a docker container and none of the within-host solutions you find anywhere else are likely to be of any use.

[Elmi (Ekmo)]

Just a quick update to let you know what worked for me.

I tried, but this didn’t worked for me.It looked like no additional certificate was issued.

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…

I also tried to solve my issue by following this suggestion, but this also didn’t work for me.

Setup Let’s Encrypt + non-www > www

I finally made it work, and thought to put everything together in case someone needs it. This info is assembled from different topics on this forum. Thanks to @brahn and @techAPJ. This assumes you’ve completed the initial Let’s Encrypt setup: After you’ve done it, the following needs to be added to the app.yml in hooks section. It will do two things: setup SSL for both example.com and www.example.com. Just replace example.com with your domain name. redirect example.com to www.example.com I…

The only thing which solved my issue so far was by following the instructions here http://www.forcewww.com/

Nevertheless, I think this is still not a desirable solution, as it relies on an external service. Of course, it is free of charge, but you’ll need to find a new solution once this service is down.
I hope you don’t get me wrong @michaeld , it’s really a nice and easy solution which you are offering and I highly appreciate it.

It would be pretty cool thing, if you could decide during the standard install to go only with a www or non www version to make our life a little bit easier

[pfaffman (Jay Pfaffman)]

@Elmi

I tried, but this didn’t worked for me.It looked like no additional certificate was issued.

Though I haven’t tested it in the just month, I’m pretty sure it works. If you didn’t have your DNS set up correctly and ran it a bunch of times then you got rate limited.

@Elmi

would be pretty cool thing, if you could decide during the standard install to go only with a www or non www

Do you mean “and request a certificate with both hostnames?” That’s way too hard. The likelihood that it will just break things for lots of people who don’t know how to configure dns that way is very, very high.

[JimPas]

@Elmi

→ https://example.com throws a certifcate error and is not redirected to the correct https://www.example.com (the certificate was issued for http://www.example.com and not for http://example.com)

@Elmi

What is the best approach to make https://example.com redirect to https://www.example.com and how can I achieve my goal?

If you create a cert for both the apex and the www version, you’ll have both covered. :smiley As you stated, the cert does not include your apex domain… thus the error.

Your redirects should be:

• http://example.com → https://example.com
• http://www.example.com → https://www.example.com.
• Then redirect https://example.com → https://www.example.com (your stated preferred domain).

Then no matter whether someone types in the apex domain or the www version, they’ll land on your https://www.example.com without any errors. Best practice is to include both the apex and the www on your cert. Just make sure your amended/new cert is the one being served by your server, and not the old one.

[Jagster (Jakke Lehtonen)]

@pfaffman

Because it’s inside of a docker container and none of the within-host solutions you find anywhere else are likely to be of any use.

I see. And now you mentioned it I’ll start to remember — that was the second reason why I put Discourse behind ”normal” Nginx. The first reason was need to do some filtering. Well, my solution isn’t anykind fancy or technically demanding but not so popular at this circle.

I must say docker is not very user friendly solution if such really trivial thing must be done using third party web-service. Otherwise docker must be very useful I reckon, unless it wouldn’t come so popular.

[Elmi (Ekmo)]

Thanks for the advice @pfaffman . I’ll give it a try again during the weekend.

and about the second topic. I see your point, but this might be something like an advanced setting or optional setting, because it is really crucial that the same content is reachable only through one domain.

[Jagster (Jakke Lehtonen)]

@Elmi

it is really crucial that the same content is reachable only through one domain

Actually it is not (unless Discourse itself doesn’t work). But if you are referring to SEO and Google such subdomain issue hasn’t been so serious for long time. Google can live with that, because there is just one domain — one is stub’ish FQDN and one with www is real one.