Same deviceID is always generated

OK - I am using 1.4.0 and a real, signed certificate, and every install has the same device ID. I understand I need to change the certName - but on install there is no way to do this. After I install, I can update it - however to get a new key - I have to delete the config (and the key name) and use -generate=“blah”. Have I missed something - is there a comandline option to specify the keyname on startup? I am using the -home option to relocate the config directory (standardized setup and config this way)

The device ID is derived from the certificate (hash). Every installation needs its own certificate.

As to cert name: That is a parameter encoded into the certificate. It cannot be changed, unless you generate and sign a new certificate. Syncthing expects the certificate Common Name field to match syncthing. If your CN fields are not named syncthing, you need to change this in syncthing’s advanced per-device options (“Cert Name”).

Certificate is what decides device id.

There are two certificates in syncthing, one for the web server which is probably what you want, one for device id, where it does not matter if its signed or not.

OK - so key and cert are used for the deviceID? and the tls encryption is https-key and cert? and the certName is for the https? I was getting cert errors when trying to connect with the key and cert files as signed and the https was the original? It properly identified the signature on the key as well.

What do you mean by TLS encryption. Both HTTPS and syncthing protocol uses TLS, so you have to be specific.

I think it’s better if you explain what you are trying to do

OK - we have a FIPS 140-2 requirement and we have signed certificates for this. I need to use this to encode the data over TLS. based on your comment it looks like the https-cert is the one I need to replace.

Having a FIPS 140-2 requirement doesn’t explain what exactly you are trying to do and what which part you are trying to protect with a signed certificate, but I guess you’ve figured your way now.

Not really - but which cert is used for the encryption for the data (TLS is not be default a secure connection)

One of the certs must be the private/public key for data going in and out of syncthing - https is forbidden in our case - but since you use TLS we are required to use signed certs from the client.

Data itself is not encrypted, the transport used by two syncthing nodes talking to each other is, I guess that’s the certificate you want to replace.

The cert file is the public part, the key file is the private key. The ones for https traffic have https prefix, the ones without https used for the peer to peer traffic.

Using the same cert file, will always produce the same ID, so if want to do this on two devices, you’ll have to get two different certificates in order for them to end up with differing device ids.

Thank you - I understand the confusion now - yes - it is the transport - not the data. So yes, that is the one I need to replace. It looks like the https-key and the key could be the same on one machine. And the cert.pem is the one used to create the hash.

Yes, they can be the same, and the cert parts can be the same.

The cert/key.pem files determine the device ID and protection for the sync connection. They must be individual to each device. The https-cert/key.pem files are for the API/GUI web server and can be the same everywhere.

I’m not 100% up to speed on what FIPS means but if it places requirements on the certificate in use for TLS then I suppose you need to manage both pairs. Or have a custom build of Syncthing that uses the right parameters for their generation, for example RSA with a certain length instead of ECDSA.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.