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 talk.vanhack.ca.key to the host(s) and rename talk.vanhack.ca.key 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.
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.
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 talk.vanhack.ca 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 *.vanhack.ca in addition to vanhack.ca (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 foo.vanhack.ca but not for bar.foo.vanhack.ca . The only ACME client I have used so far is acme.sh 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 acme.sh .
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 https://talk.vanhack.ca/ 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?
