SSL Certificate Renewal Process

Requesting the Certificate

First generate a new key and certificate request file using openssl.

openssl req -new -newkey rsa:2048 -nodes -keyout -out

Get your request (the .csr file) signed by someone. At the time of this writing I picked and ordered the PositiveSSL at ~$9/year.

The site might ask you to verify ownership of the domain, in my case it was in the form of an e-mail to

Installing the Certificate

If your certificate comes in several parts this will have to be concatinated in to one certificate. With namecheap this is how it was done:

cat talk_hackspace_ca.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > ssl.crt

Order matters here, it starts with your cert, then your providers certs all the way up to the added trust for root.

Upload the ssl.crt file and to the host(s) and rename to ssl.key. Move both of these files to /var/discourse/shared/standalone/

Reloading nginx config

SSH in to the docker container:

/var/discourse/launcher ssh app

Reload nginx:

service nginx reload

Note this only applies for renowing the SSL certs, if this is the first install the container app.yml needs to be updated to include web.ssl.template and ports 443 need to be forwarded.

More info:

Allowing SSL for discourse

1 Like


As for the initial SSL install, the server is ready. app.yml has been updated and the keys are in place, all that is left is ./launcher rebuild app step in the documentation.

This will mean downtime so do it when you are ready.

Done !


Yes, I am necroposting again but my reply is on topic: apparently the TLS certificate (from Let’s Encrypt, which means the certificate should be automatically renewed by an ACME client before the certificate expires) currently used by expired back in October (!), as shown in the following screenshot of the dialog for the certificate. I do not think it matters but I am using Vivaldi on Windows 10 Enterprise for x86-64.

Because I have personal experience using certificates from Let’s Encrypt for customers of my company, I suggest using a wildcard certificate that matches * in addition to (the wildcard only matches all subdomains but not the bare/naked domain) so you do not have to reissue the certificate to add a SAN (Subject Alternative Name) every time you want to use TLS on a new subdomain. A limitation is that the wildcard only works for one level of subdomain, meaning that it works for but not for . The only ACME client I have used so far is because certbot lacked the ACMEv2 support needed for wildcard certificates when we wanted to use a wildcard certificate soon after Let’s Encrypt introduced support for wildcard certificates but that was years ago so certbot may have added the necessary support by now; I never checked if certbot did add this support because it no longer mattered once I had a working solution, which is still in use today, using .

Edit #1: Eh, Firefox on the same computer says that the current certificate is valid:

I am not currently logged into Discourse in Firefox but I do not think that matters in this case. Windows only booted earlier this week and both Vivaldi and Firefox were only started yesterday (Thursday) and appear to be the current stable release versions. I wonder if it matters in this case that this computer (my office computer) is still using a version of Windows 10 from 2016? By now I have spent far longer than I wanted to on this subject but now I am curious about this issue; I can check with the current release of Vivaldi on Windows 7 and even the final releases of Web browsers that run on Windows XP Service Pack 3.

Edit #2: This issue seems to be caused by caching in Vivaldi on my office computer because I loaded for the first time in both Vivaldi and Firefox on both another physical computer running Windows 7 SP1 and another physical computer running Windows XP SP3 with the result that the certificate is valid and appears similar to or the same as the certificate in Firefox on my office computer. Am I still in a warren?

1 Like