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:
- 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 - I need to have 2 pairs of files within the
sslfolder:<fqdn>.[cer|key]and<fqdn>_ecc.[cert|key]
What is the difference between the_ecccertificates 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
You are absolutely right. Unfortunately, our instance is not accessible from the internet (people need to connect through VPN to access it)…
Due to GDPR restrictions and various local laws about confidential information, it is usually easier to prevent access from Internet…
1 Like
I left the default in the app.yml which uses Let’s Encrypt. This was certainly an error from my side. The key is an empty file. I believe it comes from the fact that Let’s Encrypt fails to connect back to the machine.
1 Like
Since you’re not using Let’s Encrypt, you should not use let’s encrypt, so just delete or comment out that template from your app.yml.
Also, you can edit your posts rather than replying to yourself a bunch of times.
2 Likes
Thanks for the reply. You are right the Let’s Encrypt template is activated.
That was it. Thanks!
Sorry about the replies to myself. I just wanted to quote the portion of you answer so you would know which part of your answer I was referring to.
2 Likes
Glad you got it. FYI (we’re all here to learn) you can repeatedly select text and click quote–even if you navigate to other topics!
3 Likes
Thank you. It works great!
1 Like
Is there a command option to install a new TLS certificate without running “./launcher rebuild app”?
I ask because our servers are running on v2.4.0beta5 with a custom plugin that breaks on anything after v2.5. When I run “./launcher rebuild app,” my system magically gets upgraded to v2.6.0.beta1 
I understand the right way to go about this would be to hire a developer to re-write the plugin for v2.6.0beta1, but the TLS cert expires in a month, and I feel concerned that I may not have enough time for them to complete the work.
Sure is, look at my posts from January in this topic.
1 Like
If you’re using a standard install, it’ll renew on a couple of days.
Thank you for getting back to me so quickly. I used ./launcher restart app - and it picked up the renewed Comodo/Sectigo TLS cert without any problems! LIFESAVER. I will sleep better tonight. 
1 Like