Advanced Setup Only: Allowing SSL / HTTPS for your Discourse Docker setup

It would appear that you’ve wasted the $100 if you can’t get a refund (I doubt that you can), but in spite of that, it’ll be easier to use the free cert than using the one you paid for.

2 Likes

I am seeing mix content now that I enabled Let’s Encrypt. Where do I find what to change to make everything https://?

Visit Admin -> Settings and search for ‘https’ - make sure ‘Force HTTPS’ is turned on so that all local URLs are rewritten to reference the secure path.

If you have any customisations which explicitly reference off-server HTTP resources they may need to be manually corrected.

4 Likes

I am having trouble with my SSL.

My main site (no-www) has a working SSL: https://cmox.co

My subdomain, which is a different host (DO, droplet), should be covered by the main SSL.
Subdomain: lab.cmox.co

The subdomain is throwing a 521 Error.

Upon looking into Digital Ocean, I ran the following command:


Port 443 appears to be open.

Cloudflare support shared this with me: Community Tip - Fixing Error 521: Web server is down - DNS & Network - Cloudflare Community
1.) My website is working.
2.) Per the above, I believe my host is listening to port 443
3.) I can’t find an .htacces file in /var/discourse. I don’t know how to check IP tables, or my firewall but can troubleshoot with Digital Ocean
4-8.) Not sure this is my problem. Can someone point me in the direction if they think it is? I can troubleshoot those particular issues if I know they could be culprits.

Can you help me identify if the problem is a Discourse, Cloudflare, LetsEncrypt or host (Digital Ocean) problem?

The first think you want to do is disable CloudFlare completely as it causes many problems here.

3 Likes

No. It should not. It is a different server with different everything.

You should make cloudflare dns only and run discourse-setup again to enable let’s encrypt.

3 Likes

OK, I just Destroyed my entire Droplet and started again. I did the 1-click install of Discourse and setup the SMTP. Everything was fine, the site resolved at http://159.89.186.61/

Then I ran ./discourse-setup and filled out my email address for Lets Encrypt. Then I got the following error:

When I accessed http://159.89.186.61/ again, I receive this error: This site can’t be reached

For good measure, I updated my A Record with the following:


Note that I am bypassing Cloudflare CDN and only using it for DNS.

I checked app.yml and see this:

Can y’all help me resolve this error? Thank you for your help so far! I feel like I’m nearly there!

We don’t support the 1 click install here. Only installs which follow the standard install guide. If you’re going to continue using it then you need to contact DigitalOcean for assistance.

Access by IP is also completely unsupported. Make sure DNS is pointed at the new droplet.

5 Likes

I got it all set. Thanks for your patience and support.

1 Like

What does it mean?

I have intermediate.crt how can i concatenate the cert files?

From all I remember doing this years ago, it simply copying and pasting a bunch of chunks into a single file.

I do however recommend just forgetting about this mess and going with lets encrypt.

7 Likes

I asked about DNS validation for Let's Encrypt? and was pointed here, and it looks like this method will be a pretty straightforward way for me to run an ACME client in the base OS to get and renew Let’s Encrypt certs using DNS validation.

But, of course, the cert will renew every couple of months. How can I most simply have Discourse load the new certs? I know launcher rebuild app will do it, but that seems pretty excessive–is there a less time-consuming command to accomplish this?

Perhaps I’m misunderstanding how the web SSL template works, but no rebuild should be necessary with an updated certificate. What I’d recommend is creating symlinks from /var/discourse/shared/standalone/ssl to /etc/letsencrypt/live/... or wherever the auto-renewed certs are stored.

I certainly wouldn’t think so–but nginx needs to know to use the new cert. In a non-Docker environment, I’d run something service nginx reload (without systemd) or systemctl reload nginx (with it) to do a graceful reload of the configuration and start using the new cert without interrupting existing connections.

1 Like

I’m pretty sure that if the cert is renewed then it’ll catch it. Worst case, you can see that the container gets rebooted once every couple of months, e.g., by doing a rebuild to do an upgrade.

you can gracefully restart nginx from inside the container with: sv reload nginx … or docker exec app sv reload nginx

1 Like

That sounds like it should be the ticket–for right now I’m just doing launcher restart app, but this sounds cleaner.

I just installed a new instance of discourse on one of our machines and placing the certificates as per your recommendations does not work.

Every-time I need to relaunch the application, I need to copy the SSL certificates over in order to get Nginx to accept them:

cp /root/certificates/<fqdn>* /var/discourse/shared/standalone/ssl/

where the /root/certificates folder contains the following files:

# ls -lha /root/certificates/<fqdn>*
-rw-r--r-- 1 root root 1.5K Mar 26 14:52 /root/certificates/<fqdn>.cer
-rw-r--r-- 1 root root 1.5K Mar 26 15:36 /root/certificates/<fqdn>_ecc.cer
-rw------- 1 root root 1.7K Mar 26 15:37 /root/certificates/<fqdn>_ecc.key
-rw------- 1 root root 1.7K Mar 26 14:51 /root/certificates/<fqdn>.key

Two points are surprising me:

  1. Every time the application is rebuilt, the certificates are erased and replaced by invalid ones
    That makes me wonder where the new certificates get regenerated each time
  2. I need to have 2 pairs of files within the ssl folder: <fqdn>.[cer|key] and <fqdn>_ecc.[cert|key]
    What is the difference between the _ecc certificates and the regular ones ?

Cheers,

Emmanuel

First, the usual question: what is the reason you’re going through this process, rather than using automatically renewing certs via Let’s Encrypt? Manual certs are more complicated, require a deeper knowledge of Linux system administration and cryptography, and of course aren’t free.

What are the certs? Have you looked at them? The only thing I can think of that would be creating certs automatically is Let’s Encrypt. If they’re being created, they should be valid…

ECC is Elliptic Curve Cryptography, a type of key algorithm. Presumably that cert uses the ECDSA algorithm while the “regular” one uses a different algorithm.

3 Likes

What does your app.yml look like? Do you have the letsencrypt template installed for some reason? That could be overwriting your certs, maybe.

What do the invalid ones look like?

1 Like