IMHO the second key should have at least an option to use a key signed by a formal CA-authority.
The two certificates can be found in the home directory of the folder of the user under whose account the synching instance is running (you can run multiple instances on one computer). See below for an example of the directory structure.
IMHO the config file and the gui should allow to define the path to the https certificate. In case of a formal certificate that path should be the path to the systems certificate store or as alternative option the path to lets encrypt certificates.
Certificate is saved at: /etc/letsencrypt/live//fullchain.pem
Key is saved at: /etc/letsencrypt/live//privkey.pem
I know I could make copies or perhaps even links from the formal certificates, towards the users syncthing directory, but that is in every aspect including security a very bad idea.
So I really really hope to see this simple but IMHO necessary feature soon!!
Louis
louisb@syncthing:~$ sudo ls -la /home//.local/state/syncthing
total 52
drwx------ 3 4096 Oct 25 18:27 .
drwx------ 3 4096 Oct 8 17:16 …
-rw-r–r-- 1 794 Oct 8 17:16 cert.pem
-rw------- 1 9259 Oct 12 17:53 config.xml
-rw------- 1 8453 Oct 8 17:16 config.xml.v0
-rw-r–r-- 1 794 Oct 8 17:16 https-cert.pem
-rw------- 1 288 Oct 8 17:16 https-key.pem
drwxr-xr-x 2 4096 Oct 24 22:02 index-v0.14.0.db
-rw------- 1 288 Oct 8 17:16 key.pem
Since it is work, not automatic and users should not have access to the site’s primary key.
Defining the certificate path in the config and GUI would all ready be a big step forward. Stays the problem that the pk should not be accessible for a user. You can of course mitigate that by not using a normal user account to run the service.
The example LetsEncrypt certificates are updated automatically, so referring those would guaranty up to date certificates.
I am really really flabbergasted that Syncthing does not have that option. More or less only support self signed certificates.
It doesn’t, though. Regardless of where the certificate and key are stored, Syncthing needs to be able to read them. If Syncthing is running as user X, that means user X must have permissions to read the certificate and key. It doesn’t matter if they’re stored in the user’s home directory or in /etc, you’d have to arrange permissions to make it readable just the same.
Generally the things that need those certificates (web servers etc) run as root. You can do that with Syncthing as well if you like, and even set the config directory to be /etc/syncthing. It’s not a typically recommended setup, but it’s possible.
Where the certificates are stored doesn’t really matter much in this sense, and a symlink is as good as a config option.
EDITED TO ADD: I was in error here. louis was asking about the web GUI, not the Device certificates. My apologies.
What is your use case for this?
Public websites use signed certificates and keys, and that makes sense: browser users want to connect securely to lots of different websites with a reasonable assurance that their connections are secure, without needing to think about it a lot other than to see that they didn’t get a certificate warning.
Syncthing is fundamentally different in that random browser users aren’t attempting to connect to a Syncthing Device to access the contents of a shared Folder. You either control all of the Syncthing Devices in your Cluster, or you are choosing to share your Device ID with people who will in turn share their Device IDs with you. I don’t see the need for a signed certificate for any of the use cases for Syncthing that I know about.
I don’t think the OP’s question was about the device certificate, but about the https certificate. It does make sense to use a webPKI cert here.
A symlink has exactly the same access permissions to a file as if the application was opening the file directly. There is no security gain by adding more config switches here, only some minor flexibility.