Open ten3roberts opened 1 year ago
As long as it's for testing/development where stakes are low then we can continue with self-signed certificates.
That said and opt out (--secure-only
?) at this stage is a good idea. IMHO eventually we should move into this being a default and having an opt in for accepting any cert (like curl's --insecure
).
The current state:
In github releases, a self-signed certificate and key is bundled and by default.
The server uses the bundled certificate as a single chain along with the key
The client trusts the certificate as a certificate authority along with native authorities (so that mkcert and real certificates work)
If --cert path
and --key path
are specified for server
then the bundled certificates are *not loaded, even if the path does not exist. An error is printed instead of a silent (insecure) fallback.
For the client/join the same behaviour exists for a --ca path
which opts out of the bundled, but still loads the native roots.
When deploying clients we do not want to blindly trust the in-source self signed certificate as that allows server spoofing and is really only intended for development use.
The common saying: self-signed certificates should never be used in the wild