Documentation for how to use TLS connection type without self-signed certs

[crabdancing]

Use case: I have a server that already automatically refreshes its certificates with LetsEncrypt via ACME -- meaning that my certs are verifiable against the root certificate distributed with most operating systems and devices.

Consequentially, the whole step where the client needs its own ca / cert / key files does not make sense.

Despite this, zrepl seems to ignore the root certs on the device by default, rather than trying to connect as a normal HTTPS client would. I get an error if I try to omit the self-signed cert on the push job.

Please tell me if this is a supported feature, and if so, how I can handle a conventional root-signed certificate.

[problame]

Sorry for the late reply.

The zrepl TLS transport is basically mutual TLS.

Unlike, say, HTTPS, the serving-side needs to know the client.
For example, to assign it a $client_identity based on the CN in its TLS client cert.
See https://zrepl.github.io/configuration/overview.html#how-the-passive-side-works for details on client identity.

Technically, you could use the LetsEncrypt CA as the ca on both sides.
And then just use the cert and key that was issued by LetsEncrypt.

If the Let's Encrypt CA is part of the system trust store (it usually is), you could use that as the ca. For example, on Ubuntu, /etc/ssl/certs/ca-certificates.crt.

However, I don't know if it's advisable to use LetsEncrypt-Issued certs for mTLS.
The LetsEncrypt certs certify that the cert owner is in control of the DNS name.
But what zrepl client identity wants to identify is the zrepl instance / the host machine that it runs on.
That's not the same thing.

Also, operationally, zrepl doesn't support hot-reloading of TLS certs (#202).

Moving this to Q&A.