Lensencrypt Certs name change

There are now two types of letsencrypt certs and keys

  • RSA-cert.pem, RSA-privkey.pem
  • ECC-cert.pem, ECC-privkey.pem.

Which one should i use for syncthing?

  1. does it still go in the /volume1/@appstore/syncthing/var directory
  2. are they still renamed https-cert.pem, https-provkey.pem

thanks.

Hal

Either works I believe.

It seems that synology is using the ECC

does that make a difference?

image

It should make no difference which one you use.

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.

Andre,

So I am using the synocommunity package.

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

both times I applied this set of commands:

sudo chown sc-syncthing:syncthing https-cert.pem && sudo chown sc-syncthing:syncthing https-key.pem && sudo chmod 640 https-cert.pem && sudo chmod 600 https-key.pem (this is what I’ve always done)

both times when I tried to open mynas.net:8384 I get a security warning and have to choose to proceed. (see attached screen shot)

Apparently the cert it is using is an unverified synology one (see attached screenshot).

This worked for me before I renewed my letsencrypt cert.

I’d appreciate any suggestions.

Thanks

Hal

image

Did you restart Syncthing after replacing the files? They are only loaded when it’s starting up.

yes. mny times

BTW, that would be great!

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.

Andre,

thank you for the quick response

  1. What happens when you accept the security warning, do you actually get to the Syncthing GUI?

It opens the syncthing GUI

  1. is it the same IP address

Yes

  1. I used your script. I changed sudo cp -v --preserve=timestamps ${SYSTEM_CERT_DIR}/cert.pem ${SYNCTHING_CONF_DIR}/https-cert.pem

to

sudo cp -v --preserve=timestamps ${SYSTEM_CERT_DIR}/ECC-cert.pem ${SYNCTHING_CONF_DIR}/https-cert.pem

same problem. what I don’t understand is that this worked before I renewed the lensencrypt certificate.

hal

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.

There is some more brain juice comparing the two:

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.

Andre,

Thank you for the response.

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 guess this on hold until then.

hal

So, I got a new certificate. It’s working for my web site. I used your script. a couple of things:

  1. there are now two certs ECC and RSA. I had to change the cp target names to ECC-cert.pem and ECC-key.pem.

  2. 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 cp target 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.

  1. 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.

  2. the ssh tunnel into the syncthing server:

  • issuer=O = Syncthing, OU = Automatically Generated, CN = synology
  1. on the machine that the syncthing brower is opened on:
  • issuer=O = Syncthing, OU = Automatically Generated, CN = synology
  1. 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
  1. on the NAS:
  • issuer=C = US, O = Let’s Encrypt, CN = R3
  1. /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:

sudo openssl x509 -in /var/packages/syncthing/target/var/https-cert.pem -noout -text

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.

Thank you again for your help. I’m sorry for not posting the directory info before.

MyAccount@Synology:~$ ls -al /var/packages/syncthing/target/var/ total 32

drwxr-xr-x 2 sc-syncthing sc-syncthing 4096 Nov 15 16:19 .

drwxr-xr-x 5 sc-syncthing sc-syncthing 4096 Nov 12 16:51 …

-rw------- 1 sc-syncthing sc-syncthing 2667 Jun 19 13:29 config.xml

-rw-rw-r-- 1 sc-syncthing syncthing 1833 Nov 13 23:20 https-cert.pem

-rw------- 1 sc-syncthing syncthing 1708 Nov 13 23:20 https-key.pem

-rw-r–r-- 1 sc-syncthing sc-syncthing 208 Jun 19 13:29 options.conf

  1. the two commands produce different certs. The issuers are:

a) sudo openssl x509 -in /var/packages/syncthing/target/var/https-cert.pem …

  • Issuer: C = US, O = Let’s Encrypt, CN = R3

b) openssl s_client -connect localhost:8384

  • issuer=O = Syncthing, OU = Automatically Generated, CN = synology
  1. when I say NAS browser I meant the login to the Synology Desktop.

Our auto generated GUI certificates do in fact have the system host name as CN (and dnsName), and the mentioned O and OU values. It’s unfortunate that it becomes a bit confusing when the host name is synology.

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:

  1. 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.

  2. 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.