Are there any in-depth, “for dummies” guides for using Letsencrypt with the Syncthing webUI on linux? I tried making systemlinks to the letsencrypt files (cert.pem -> https-cert.pem, privkey.pem -> https-key.pem) and adding read permissions, but I kept getting “premission denied” errors for https-cert.pem/https-key.pem when starting to syncthing.
A good guide on the SSH tunnel access would work too.
You probably have insufficient permissions for the user running syncthing somewhere in the directory chain to the pem files.
For symlinks to work, the whole path must be accessible (x perm on directories).
I did this setup a year ago, or so. I had similar issues and I ended up creating a cronjob that copies the cert from /etc/letsencrypt to syncthing’s config directory from time to time. Also note that syncthing only reads the certificates at startup, so you need to restart syncthing at least every 2-3 months to avoid using outdated certificates. Due to the fact that syncthing releases regular updates which perform auto-restart on install, it is usually not much of an issue.
I assume that there are better ways to solve this (e.g by actually fixing the permissions), but I probably just didn’t care enough. I needed a similar setup for another application anyway, so I just went with the cronjob.
Also I should mention that setting up some (nginx) reverse proxy for https access may be the better solution anyway, since that may reduce attack surface and you don’t need the gui port accessible from the net.
Is there a comprehensive list of files/directories that need to have their permissions modified (and a list of required permissions)? I understand the “theoretical underpinnings” of why it’s not working. I am looking for a practical solution that references this particular use case (i.e. HTTPS on syncthing webUI). For what it’s worth I’ve also added read permissions to the directory where cert.pem/privkey.pem are stored.
Would you be willing to share a generic copy of your cron job and some basic instructions (which user creates the cron job, what permissions need to be changed etc)? I am a n00b at linux.
I would love to run nginx for the webUI, I use this approach for one of my other services. But I can’t do this unless there is a clear, user-friendly, outcome-focused guide on how to do this.
Parts 1 and 2 make sense to me. I don’t feel confident about my interpretation of part 3. What hook are you referring to? I am not a certbot expert.
Syncthing’s web UI uses HTTPS by default. You’re looking for a comprehensive guide to your specific Lets Encrypt setup, which I think we cannot provide - beyond the generic “make sure Syncthing can read the certificate you want it to use”.
I would look for a guide on whatever tooling it is you’re using for Lets Encrypt, where Syncthing is just any third party software that wants to use the certificate in question.
Okay, I will try to give some short tutorials on a few of your questions:
Approach 1: Using a cronjob to manually copy the certificate
Make sure syncthing has the https-key.pem and https-cert.pem files present in it’s home directory; my commands assume the directory is /home/syncthing/.config/syncthing [that’s my setup). Make sure the permissions are correct, meaning the files are owned by the user running syncthing. The easiest way to achieve this is by deleting the current files while syncthing is stopped.
Upon the next start, syncthing will re-generate the https-key.pem and https-cert.pem files with the correct permissions (files are owned by user running syncthing). Now, you only need to overwrite the files - overwriting existing files does not change their permissions.
Open a shell/terminal on the machine, preferably as root or any other user that definetly has access to all certificates inside of /etc/letsencrypt. You can get root either by typing in su or by prefixing the following command with sudo.
Type crontab -e to edit the crontab of the current user
The file will be opened with some text editor, like nano. In the file, below the comments you can add the following lines:
This would copy the certificates from the let’s encrypt directory daily to the syncthing directory, overwriting existing files but without modifying file permissions. The solution is simple, but definetly not the best. The @daily should be supported by pretty much every standard cron and tells the system to run the command every day, I believe it’s at midnight.
Approach 2: Syncthing behind nginx reverse proxy
It’s actually fairly straightforward, assuming that you already got nginx up and running. To prevent this guide from blowing up the forum, I will assume you already got that.
Every proper nginx-tutorial should tell you to create your configuration in a seperate file which should live inside /etc/nginx/sites-available. I will assume that you already have such a file and that it is called reverse-proxy.conf
To setup a reverse proxy, open the file reverse-proxy.conf and make it look like this generic example. The file should include your old configuration (if any) and the new one.
I believe what’s meant is that certbot supports additional actions (called hooks) that are executed whenever certbot performs certain actions, such as renewing a certificate. You could create a hook that automatically restarts syncthing whenever certbot renews your certificate. A good piece of documentation to start with is here: https://certbot.eff.org/docs/using.html#renewing-certificates
Thank you! This is exactly what I was looking for.
I didn’t realize that overwriting existing files does not change the files’ permissions.
After creating the cron jobs, I ran the cp commands before restarting the syncthing service and HTTPS webUI works! I did get a warning from Firefox, but I believe this normal? Is there any way to verify that the cron job will executed successfuly? A log of some sort perhaps?
I will look into hooking up nginx at a later date. Seems doable. Would this work in concert with the HTTPS certificates? The certbot hooks seem a bit above my skill level.
I don’t mean to sound arrogant or ungrateful and I genuinely appreciate the effort you put into syncthing (I like how it is “clean” and transparent once you get everything setup), but I have to disagree with you on this one.
I don’t see how the existence of a quick ~300 word guide on getting HTTPS webUI working with letsencrypt harms anyone. I understand that integrating “auto key import” into the syncthing for linux or even including this in official documentation might be out of scope, but there is nothing wrong with offering some sort of documentation on integration with 3rd party services.
I searched around for guides and I found that many other users had similar problems with getting HTTPS to work, so I am not the only one.
This is just my perspective as someone who is not a pro at linux, nothing more or less.
The cp command follows an old GNU convention, which is that the program does not output anything, if the operation was successfull. If something failed, it will however present you a warning or error message.
The warning in Firefox however sounds like something went wrong. Certificates from Let’s Encrypt are specifially designed to not trigger any warning from the browser side, unless something is misconfigured.
The self-signed certs from syncthing however will definetly trigger a warning inside the browser, because they’re untrusted. To avoid this you want to overwrite them with your Let’s Encrypt cert.
The cronjob itself will email any program outputs to an email-address, if you configure it do so by adding the line MAILTO="root@localhost" or similar above the @daily stuff.
That’s strange, because the same certificate works fine on the main web services (a cloud music player). I had to add an exception, but detailed info in Firefox suggests that the connection is encrypted.
I will see what happens when the cron job executes.
Make sure you’re using the file fullchain.pem as the public key/certificate and not the file cert.pem. The latter is missing the Let’s Encrypt Intermediate certificate, which the browser requires to validate the certificate.
The connection is always encrypted, but https/TLS does not only provide encryption - for encryption you don’t need any certificates at all. The certificate is used to provide authenticity, to prevent man-in-the-middle. If you accept a warning from your browser concerning the certificate, you’re possibly loosing authenticity and trust whoever the other party is - unless you manually verify the fingerprint of the certificate.