So you’d like to add https to your Discourse absolutely free, courtesy of our friends at Let’s Encrypt?

Is everything else on your site ready for HTTPS?

Before you start, please bear in mind that for HTTPS to work properly, every single resource on the page must be HTTPS compatible. Consider your CDN, your social logins, your logo files, any third party JavaScript, images, fonts, or css — these all must be available over HTTPS!

Note:./discourse-setup will enable Let’s Encrypt. And as of March 2017, you can run it again, and press return a few times and enter your email address ; the script will include the required templates and insert your email address as required. If you installed Discourse a long time ago, you might still have to edit app.yml by hand.

Note: If your Discourse is accessed via some reverse proxy (e.g., Cloudflare) this will not work.

For the next few steps, you will be editing the app.yml file for your Discourse instance:

Is Discourse the only website on your server?

If you are already using web.socketed.template.yml, because you host other websites via port 80 on the same server, stop. You should be using a Let’s Encrypt client on the host system; the validation will fail as the client used is unable to bind to the necessary sockets.

web.letsencrypt.ssl.template.yml adds a startup script to your container that

Issues a Let’s Encrypt cert using the standalone mode. It boots a standalone server that listens on port 80 but this happens before nginx is up so port 80 is free.

Installs the cert into the right directory that nginx expects. At the same time, it adds a cron job that runs a daily cert renewal check. This will automatically renew your cert. Nothing happens if cert has not expired. If the certificate does expire, you’ll get an email about it from Let’s Encrypt at the email address you provided during setup.

Switches the script to use the webroot plugin with /var/www/discourse/public as the directory. This will allow us to use nginx as the server that handles domain validation. Zero downtime during cert renewal!

Debugging

Check logs for cert related errors

./launcher logs <container name>

Then look for any errors mentioning letsencrypt or SSL.

Did the cert files get written OK?

ls -l /var/discourse/shared/standalone/ssl on the host server

You should have a certificate .cer and key .key file for your domain, and they should have ~3k filesize.

Delete the old cert files and try rebuilding again

Limitations

Though the Let’s Encrypt certificate is valid and safe for encrypting data, it does not certify that the site is owned by a particular organization. Firefox will complain that the certificate “does not supply ownership information.” This is a limitation of how Let’s Encrypt works. For more information see: Adding Ownership Information? - Help - Let’s Encrypt Community Support.

When discourse is setup as a root domain (e.g. without “www”), the certificate is issued to the root domain only. Is there a way of configuring this so that both the root and the www versions work - e.g. so that we don’t get certificate errors on www.example.com when discourse is setup for example.com.

I believe Neil’s script allows for this using the -d option to specify multiple hosts for the certificate (so a SAN is used in the cert), so possible that we need to cater for this in the web.letsencrypt.ssl.template.yml somehow. Maybe by adding another variable into app.yml (e.g. DISCOURSE_ALT_HOSTNAME: ‘www.example.com’), and then pick this up in the script in web.letsencrypt.ssl.template.yml.

Meanwhile, can we manually run commands to do this without anything being overwritten on restart? Or is it okay to edit the conf file for the domain and set a value for Le_Alt ? If we alter the value for Le_Alt, how do we then force a reissue and install of the cert?

Adding multiple domains has been done before. I’ll like to bake this into the template though, we should probably take in an additional env variable and add that into the issue command. Hopefully someone from the community can take this?

@tgxworld Thanks for the link. If I make these changes, I’m assuming that the script won’t update the cert until renewal because it will see a valid certificate already installed. How do I force it to update?

I didn’t implement the file changes in app.yml, partly because I wanted to keep the build as standard as much as possible.

However, using the info from that post and your tip on FORCE=1, I did the following (posted here just in case someone else wants to do the same):./launcher enter app vi /etc/runit/1.d/install_ssl_cert sv stop nginx FORCE=1 /etc/runit/1.d/install_ssl_cert sv start nginx

In the edit of install_ssl_cert, I changed the first line (after #!/bin/bash) to:LE_WORKING_DIR="/shared/letsencrypt" /shared/letsencrypt/le.sh issue no example.com www.example.com 4096

Checked the certificate after install and it is now complete with and without “www”.

Is it possible to (easily) change when the script agrees to renew the script?

At the moment, it looks like the cert renewal is about 9 days before it expires. In the meantime, Let’s Encrypt has sent me two reminder emails saying that the cert is going to expire.

I’d prefer to have the cert renewed as soon as it possibly can so that I only get the LE reminder emails if, for some reason, the renewal process has failed and I therefore need to investigate further.

Of course, as soon as I post, I find the issue. My site only passes 443 to Discourse as other things run on 80 - and of course the renewal has to happen on 80… as soon as I added a vhost on 80 to handle .well-known, all was fine. Thanks anyway!

I followed this guide after setting up a new discourse “one-click” droplet on Digital Ocean. Just wanted to say thanks, it worked perfectly. Pretty awesome that uncommenting a few lines and restarting gives you SSL for free!

No, using Cloudflare for SSL, without also setting up SSL on your server, is terribad – it lulls users into a false sense of security, whilst funnelling your site’s unencrypted traffic through a small number of very attractive targets (Cloudflare data centres).

No, using Cloudflare for SSL, without also setting up SSL on your server, is terribad – it lulls users into a false sense of security, whilst funnelling your site’s unencrypted traffic through a small number of very attractive targets (Cloudflare data centres).

Thanks for info. I was read about hackers vs cloudflare at february 2017. So i understand. Anyway. There is any pros for using the Cloduflare or not really. If i understand:
SSL - lets encrypt is ok , or any paid ssl
DNS - my own register (like ovh, godaddy) or premium (for 10 dolars) DNS ? This is worth it ?
Anythink else should i get or good to know?