Non www to www without certificate error

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

1 Like

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

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.

2 Likes

Beware for duplicate content in search engines.

3 Likes

This is an area that I’m not that hot on. :slightly_smiling_face: 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.

2 Likes

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

3 Likes

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

2 Likes

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

2 Likes

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

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.

2 Likes

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.

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

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 :slight_smile:

2 Likes

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.

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.

2 Likes

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.comhttps://example.com
  • http://www.example.comhttps://www.example.com.
  • Then redirect https://example.comhttps://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.

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.

2 Likes

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.

2 Likes

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.

1 Like

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