Making 'www' work with Discourse

Support
21

Nope, no additional install.

Also, the only block I needed to add is:

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d mywebsite.org --keylength"

(http to https redirect seems to be working fine without the two other replace blocks, those with nginx)

2 Likes
22

So I’ve finally found time to work through the “Setting up Let’s Encrypt with Multiple Domains” and “Redirect single/multiple domain(s) to your Discourse instance” guides.

I’ve added a lot more to my containers/app.yml file than you did and nearly everything works correctly.

My Discourse is hosted on the www. subdomain and my goal was to redirect http and https requests from the apex domain to the www subdomain. This now works but if I go to https://mydomain.com, it does redirect but Chrome the following warning in the console:

Redirecting navigation example.com -> www.example.com because the server presented a certificate valid for www.example.com but not for example.com. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling

Here’s my app.yml additions:

 after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
          return 301 https://$host$request_uri;
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /gzip on;[^\}]+\}/m
        to: |
          gzip on;
          add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain
  after_web_config:
    - replace:
        filename: /etc/nginx/nginx.conf
        from: /sendfile.+on;/
        to: |
          server_names_hash_bucket_size 64;
          sendfile on;
    - file:
      path: /etc/nginx/conf.d/discourse_redirect_1.conf
      contents: |
        server {
          listen 80;
          listen 443 ssl;
          server_name example.com;
          return 301 https://www.example.com$request_uri;
        }

Does this look correct? If so, is there a solution to the certificate name mismatch problem?

EDIT: I have two A Records, one for the www subdomain and another using @ to catch all requests to the apex domain. Both point to my Digital ocean droplet IP. I assume this is also correct?

Thanks.

1 Like
23

Free to implement, even if cloudflare isn’t your registrar. Works with https, zero additional complexity in your discourse install.

24

Thanks, I am not currently using Cloudflare so hadn’t come across those before. I went a different route and followed the guides above and mostly managed to solve my problem. You posted just as I submitted my reply above.

25

Please check this website; does it have all the redirects you need? It’s done with only one replace block (see above) and this DNS setup (I’ve only redacted the email TXT records):

image
image1421×550 14.9 KB

I get no warning in the console.

26

Yep, just be prepared for it to break when the letsencrypt configuration changes.

When Lets encrypt was updated to support elliptical curve the approach you’re relying on above was broken for a couple of weeks.

1 Like
28

The only difference is I do not have the CAA record in my DNS. I’ll add it using the same value you’ve used.

I assume your discourse hostname is www.example.com, are you certain you do not get a warning when you access https://example.com?

The warning is even more severe with Chrome on Android, it blocks the site completely and doesn’t redirect.

29

You’ve lost me now :slight_smile: What do I need to watch out for/be prepared to fix?

30

Correct.

Yes I am, no warning in the console.

31

I think I found the issue, I had this:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"

When I should have had:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com --keylength"

Notice the last line, I had example.com and www.example.com

I also changed return 301 https://$host$request_uri; to return 301 $scheme://$host$request_uri; a rebuild later and it seems to be working.

Now I’m just concerned about what @Stephen mentioned about it breaking when letsencrypt configuration changes…

3 Likes
32

A change on September 9th last year broke the approach you’re following, and because the implementation falls outside of the standard install it wasn’t until the October 31st that a solution was published. If you look at the topic you followed and the edit history on the wiki it’s clearly documented.

As you’re not doing something which necessitates getting elbow-deep in additional configuration, I would advise against it. OTOH when Let’s Encrypt does change and you’re affected, we can refer you back to this topic.

1 Like