To be on the safe side, you should use /usr/local/syncthing/var/ as the location. The files are named https-cert.pem and https-key.pem.
By the way, I have a pull request open to integrate the Syncthing SPK package with certificate management on Synology’s DSM. From there you can request and renew Let’s Encrypt certificates with just a few clicks. Hope that gets accepted soon. Assuming you are using the package from SynoCommunity, not from Kastelo, Inc.
I tried coping the ECC-cert.pem and the ECC-privkey.pem into /usr/local/syncthing/var. When that didn’t work I rm-ed them and tried copying the cert and privkey the /volume1/@appstore/syncthing/var. That didn’t work either
I don’t have any idea why it might not be working in your case. Are you sure it’s the right port? What happens when you accept the security warning, do you actually get to the Syncthing GUI? Are you 100 % certain that the device where you installed the files is the same IP address you are testing against?
Please double-check again that your copying of PEM files actually results in the right state. Look at Syncthing’s home directory again closely, as in sudo ls -al /usr/local/syncthing/var/. As a reference, I posted a my script for copying renewed certificates to be used by Syncthing on DSM in a different thread, see below. Hope that may help you to spot what’s different in your procedure. My script just copies the “system” certificate from DSM, so whatever you configured as “Default” in the Control Panel will be used. Easy to adapt for copying certificates from a different source though.
I beleive that ECC (eliptic curves cryptography) is supposed to be more modern/secure than RSA. RSA is classic OG algorithm proven by the time. However ECC is not exactly young either, both should provide reasonable security for most usecases and you don’t have to worry about your choice. Letsencrypt would not give you certificate using unsecure algorithm. ECC might not be supported by relatively old browsers, but i am not sure. Also there might be slight variations of “speed” between the two. But i gues that is not important for syncthing GUI as it does not get too much traffic unless you run some crazy setup with 10000 shares in single web interface.
Sorry @halteach I’m still clueless as to why it would serve the Synology self-signed certificate. In theory, the DSM can be set up to do reverse-proxying for some services, but that is definitely not done for the Syncthing package. It would probably lead to the “system” certificate being used for the connection though.
There’s not much logging going on when setting up the API server in Syncthing, regarding the certificates. You would notice from the logs that Syncthing regenerates a new certificate if the old one was not valid. But then you’d see a self-signed “syncthing” certificate, not “synology”. So I’m afraid debug logging would not help you much here.
Maybe fiddle around with the openssl s_client tool to inspect the presented certificate. Once from the NAS itself over SSH and then from your client to the NAS IP. See if anything may be exchanging the certificate in between.
So, I’m a little embarrassed. In trying to figure things out, I deleted and renewed my letsencrypt cert too many times. After the last deletion they wouldn’t let me get a new one. Now I have to until friday before they’ll let me get a new one.
So, I got a new certificate. It’s working for my web site. I used your script. a couple of things:
there are now two certs ECC and RSA. I had to change the cp target names to ECC-cert.pem and ECC-key.pem.
there is no /usr/local/syncthing directory. I saw this when i first started having the trouble. i have to use /volume1/@appstore/syncthing
So neither the ECC or RSA cert worked. it’s still using the synology cert
I don’t know what the openssl s_client tool is. I was able to run it on a ssh session but i have I didn’t understand the output and I don’t know how I should be using it.
That’s strange, the /usr/local/syncthing/var directory should definitely exist, just as /var/packages/syncthing/target/var. You say you changed the cptarget names to ECC-*.pem? That would be wrong, as Syncthing definitely only looks for https-*.pem. Can you post the output of the script? It shows a directory listing to confirm what was done.
To verify whether anything hijacks the connection, examine the output of this command: openssl s_client -connect localhost:8384 on the NAS and openssl s_client -connect YOUR-NAS-IP-ADDRESS:8384 on the machine where you open the browser. Look for lines starting with issuer=.
First, Thank you for your help and quick replies. I greatly appreciate it.
By target I meant the source files which are now either ECC-cert.pem, ECC-privkey.pem, RSA-cert.pem or RSA-privkey.pem. The files created by the copy are https-cert.pem and https-key.pem.
the ssh tunnel into the syncthing server:
issuer=O = Syncthing, OU = Automatically Generated, CN = synology
on the machine that the syncthing brower is opened on:
issuer=O = Syncthing, OU = Automatically Generated, CN = synology
When i run the command on the machine I open the NAS browser (not syncthing browser) with the NAS IP, ie, NAS-IP-ADDRESS:5002 i get:
issuer=C = US, O = Let’s Encrypt, CN = R3
on the NAS:
issuer=C = US, O = Let’s Encrypt, CN = R3
/var/packages/syncthing/target/var exists is a link to /volume1/@appstore/syncthing/var
You still have not provided the directory listing I have asked for several times:
ls -al /var/packages/syncthing/target/var/
I have no clue where you got such a certificate from. The auto-generated ones from Syncthing have only CN = syncthing on them. No O or OU fields and definitely not CN = synology. You can verify if the used certificate matches the file you are copying it to:
Now compare that to what you saw with the openssl s_client -connect command.
When you say “Syncthing browser” vs. “NAS browser”, you mean the Web GUI of the respective software, right? The browser is probably always the same piece of software running on your client machine.
Ah! That behavior was introduced more recently than my Syncthing instances last generated a certificate. It was added in November 2020.
So now it’s clear that:
The certificate you’re seeing in the browser is not one issued / generated by Synology’s DSM, but the default one generated by Syncthing itself.
The PEM file is definitely not being picked up by Syncthing. Are you sure that you did restart Syncthing after putting that certificate file there?
If you used my script, there should have been an output of {"ok": "restarting"} at the end. If not, you might have entered the wrong API key in the script? Please make sure to include command output so we can see if the suggested commands actually worked, otherwise it’s difficult to follow what you tried.
One thing I noticed in your directory listing is the owner group sc-syncthing instead of syncthing on all other files. It should not make a difference, but you could try to adjust the ownership (SYNCTHING_GROUP variable in the script). And it’s a little strange that the config.xml file was last modified on June 19th. Did you really not change anything in Syncthing since then? Otherwise this would indicate that maybe you’re looking at the wrong directory after all.
okay. it seems that syncthing is using /volume1/@appdata/syncthing as it’s “var” directory. here is a listing of that directory:
sh-4.4# ls -al /volume1/@appdata/syncthing/
total 92
drwx------ 3 sc-syncthing sc-syncthing 4096 Nov 16 06:24 .
drwxr-xr-x 25 root root 4096 Sep 7 07:53 …
-rw-r–r-- 1 sc-syncthing syncthing 794 Nov 16 06:23 cert.pem
-rw-r–r-- 1 sc-syncthing syncthing 794 Nov 16 05:38 cert.pem.bak
-rw------- 1 sc-syncthing syncthing 6409 Nov 16 06:19 config.xml
-rw------- 1 sc-syncthing syncthing 99 Nov 16 06:24 csrftokens.txt
-rw-rw-r-- 1 sc-syncthing syncthing 1557 Nov 16 05:31 https-cert.pem
-rw------- 1 sc-syncthing syncthing 241 Nov 16 05:31 https-key.pem
drwxr-xr-x 2 sc-syncthing syncthing 4096 Nov 16 06:24 index-v0.14.0.db
-rw------- 1 sc-syncthing syncthing 288 Nov 16 06:23 key.pem
-rw------- 1 sc-syncthing syncthing 288 Nov 16 05:38 key.pem.bak
-rw-r–r-- 1 sc-syncthing syncthing 208 Jun 19 13:29 options.conf
when i make setting changes the config.xml is updated.
i have copied the letsencrypt cert and key into the directory as https-…
I renamed the cert.pem and the key.pem with a .bak extension
when i run the cert install script it does restart syncthing so, i have the correct API key
when i restart syncthing it creates cert.pem and key.pem.
But, it is now using the letsencrypt key for the browser window
success i think!
one weird behavior: When I make changes in the settings and restart the changes are gone and I can’t view the api key (the box is gray). However, if I look in Advanced, I can find the api key and the changed settings.
Just for the record, the three paths we tried all point to the same on my Synology. I just tend to use one which doesn’t depend on the install location (volume3 instead of volume1 for me), but in your case they seem to have been disconnected somehow.
admin@box:~$ sudo ls -l /var/packages/syncthing/target/var
Password:
total 1408
-rw-rw-r-- 1 sc-syncthing syncthing 619 Jan 1 2019 cert.pem
-rw------- 1 sc-syncthing syncthing 58599 Oct 18 22:07 config.xml
-rw------- 1 sc-syncthing syncthing 297 Oct 17 19:36 csrftokens.txt
-rw-rw-r-- 1 sc-syncthing syncthing 1915 Aug 16 23:07 https-cert.pem
-rw------- 1 sc-syncthing syncthing 1675 Aug 16 23:07 https-key.pem
drwxr-xr-x 2 sc-syncthing syncthing 4096 Nov 2 18:42 index-v0.14.0.db
-rw------- 1 sc-syncthing syncthing 288 Jan 1 2019 key.pem
-rw-r--r-- 1 sc-syncthing syncthing 261 Aug 2 2019 options.conf
-rw-r--r-- 1 sc-syncthing syncthing 832 Aug 2 2020 syncthing_install.log
-rw-r--r-- 1 sc-syncthing syncthing 1338995 Nov 16 14:09 syncthing.log
-rw-r--r-- 1 sc-syncthing syncthing 6 Nov 2 00:26 syncthing.pid
admin@box:~$ sudo ls -l /usr/local/syncthing/var
total 1408
-rw-rw-r-- 1 sc-syncthing syncthing 619 Jan 1 2019 cert.pem
-rw------- 1 sc-syncthing syncthing 58599 Oct 18 22:07 config.xml
-rw------- 1 sc-syncthing syncthing 297 Oct 17 19:36 csrftokens.txt
-rw-rw-r-- 1 sc-syncthing syncthing 1915 Aug 16 23:07 https-cert.pem
-rw------- 1 sc-syncthing syncthing 1675 Aug 16 23:07 https-key.pem
drwxr-xr-x 2 sc-syncthing syncthing 4096 Nov 2 18:42 index-v0.14.0.db
-rw------- 1 sc-syncthing syncthing 288 Jan 1 2019 key.pem
-rw-r--r-- 1 sc-syncthing syncthing 261 Aug 2 2019 options.conf
-rw-r--r-- 1 sc-syncthing syncthing 832 Aug 2 2020 syncthing_install.log
-rw-r--r-- 1 sc-syncthing syncthing 1338995 Nov 16 14:09 syncthing.log
-rw-r--r-- 1 sc-syncthing syncthing 6 Nov 2 00:26 syncthing.pid
admin@box:~$ sudo ls -l /volume3/@appstore/syncthing/var
total 1408
-rw-rw-r-- 1 sc-syncthing syncthing 619 Jan 1 2019 cert.pem
-rw------- 1 sc-syncthing syncthing 58599 Oct 18 22:07 config.xml
-rw------- 1 sc-syncthing syncthing 297 Oct 17 19:36 csrftokens.txt
-rw-rw-r-- 1 sc-syncthing syncthing 1915 Aug 16 23:07 https-cert.pem
-rw------- 1 sc-syncthing syncthing 1675 Aug 16 23:07 https-key.pem
drwxr-xr-x 2 sc-syncthing syncthing 4096 Nov 2 18:42 index-v0.14.0.db
-rw------- 1 sc-syncthing syncthing 288 Jan 1 2019 key.pem
-rw-r--r-- 1 sc-syncthing syncthing 261 Aug 2 2019 options.conf
-rw-r--r-- 1 sc-syncthing syncthing 832 Aug 2 2020 syncthing_install.log
-rw-r--r-- 1 sc-syncthing syncthing 1338995 Nov 16 14:09 syncthing.log
-rw-r--r-- 1 sc-syncthing syncthing 6 Nov 2 00:26 syncthing.pid
The settings dialog not reflecting changes sounds like a browser problem to me. Have you tried force-reloading the page (Ctrl-F5 for me in Firefox)?
However it seems that the directory that my instance of syncthing is using is different than the 3 you describe above, /volume1/@appdata/syncthing. These seem to be real directories and not links as far as I can tell. When I check the 3 directories in your reply above:
/usr/local/syncthing/var does not exist.
The other two have not changed.
Is this okay? BTW, on the last go round I uninstalled syncthing (removing all files), rebooted the NAS, reinstalled syncthing. That’s when I found the “working” directory.
In terms of settings, it seems that settings will be saved, config.xml changes, only if I’m connected by http://. Updating the advanced will work all the time.