Configure o suporte a HTTPS com Let's Encrypt

[Discourse]

This is a guide for enabling HTTPS on an existing Discourse installation using Let’s Encrypt. It assumes prior installation without HTTPS enabled.

Required user level: System Administrator

This guide is only for existing installs where HTTPS is not enabled. Following the official setup guide automatically enables HTTPS by default.

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. Unless you are an expert sysadmin and know a reason not to do that, you should run discourse-setup rather than read any further. (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 configuration will not work.

Configure HTTPS with Let’s Encrypt

1. Edit app.yml

Access your Discourse’s configuration file:

cd /var/discourse
nano containers/app.yml

• Add the following templates:

  templates:
    - "templates/web.template.yml"
    - "templates/web.ssl.template.yml"
    - "templates/web.letsencrypt.ssl.template.yml"
  

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.

2. Expose HTTPS ports

Ensure the following ports are exposed for HTTPS traffic:

expose:
  - "80:80"
  - "443:443"

3. Add email for Let’s Encrypt

Insert the email address for Let’s Encrypt notifications:

env:
  LETSENCRYPT_ACCOUNT_EMAIL: 'your-email@example.com'

4. Rebuild the application

Apply the changes by rebuilding the container:

./launcher rebuild app

5. Validate HTTPS

Access your site via https://yourdomain.com. If successful, you’ll see your site secured with HTTPS.

Review your resources:

• Ensure assets (e.g., images, scripts) load over HTTPS.
• Reconfigure social logins and CDN for HTTPS as required.
• Address any warnings in the browser console about insecure assets.

Discourse automatically enables force_https after a rebuild with a valid HTTPS certificate.

How does it work?

The template uses GitHub - acmesh-official/acme.sh: A pure Unix shell script ACME client for SSL / TLS certificate automation which is

Simplest shell script for LetsEncrypt free Certificate client

Simple and Powerful, you only need 3 minutes to learn.

Pure written in bash, no dependencies to python , acme-tiny or LetsEncrypt official client. Just one script, to issue, renew your certificates automatically.

Probably it’s the smallest&easiest&smartest shell script to automatically issue&renew the free certificates from LetsEncrypt.

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

1. 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.
2. 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.
3. 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!

Troubleshooting

Checking logs

If HTTPS doesn’t work, check logs for SSL or Let’s Encrypt errors with:

./launcher logs app

Verifying certification files

Ensure certificate and key files are in place with:

ls -l /var/discourse/shared/standalone/ssl

You should see files like:

• yourdomain.com.cer
• yourdomain.com.key

Renewing certificates manually

If auto-renewal fails, you can manually reissue your certificate:

./launcher enter app
sv stop nginx
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf
LE_WORKING_DIR=/shared/letsencrypt DEBUG=1 /shared/letsencrypt/acme.sh --issue -d example.com -k 4096 -w /var/www/discourse/public
LE_WORKING_DIR=/shared/letsencrypt /shared/letsencrypt/acme.sh --installcert -d example.com --fullchainpath /shared/ssl/example.com.cer --keypath /shared/ssl/example.com.key --reloadcmd "sv reload nginx"
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf -s stop

Rebuilding with clean certs

Remove old certificate files and rebuild to start afresh:

rm -rf /var/discourse/shared/standalone/ssl
rm -rf /var/discourse/shared/standalone/letsencrypt
./launcher rebuild app

Limitations

Let’s Encrypt certificates only validate the domain and encryption. They don’t confirm ownership or identity, which may be flagged in some browsers. For more details, refer to the Let’s Encrypt community.