Pin a certificate for a native remote

A native host:port remote requires a pinned certificate:

tovio clone <host:port> <repo> <dir> --cert server.der

A hosted https:// remote does not — it verifies through the ordinary public chain, and passing --cert to one is refused rather than ignored.

Why pinning rather than trust-on-first-use

A native remote is typically a machine with no publicly-issued certificate. Accepting whatever it presents on first connection would make the first connection the vulnerable one, and TOVIO's whole premise is that the transport carries content whose access control you are relying on.

There are three pins, not one

These are independent and all must hold. A valid TLS session proves the channel is intact, not which relay is on the other end — that is what the serving-identity pin catches, including a relay that terminates and re-originates the connection. Under owner-is-Key-Authority, that same pinned identity is what verifies teammates' write proofs, so it is load-bearing beyond transport.

Getting the certificate safely

From the operator, over a channel you already trust. Fetching it from the same host you are about to connect to proves nothing.

Storing it

tovio remote add origin <host:port> <repo> --cert server.der

Recording it with the named remote means you are not passing --cert on every command. A clone already saves the pin for its own origin automatically.

If it stops matching

The connection fails rather than falling back. Either the server rotated its certificate or key — get the new one from the operator, and for a deliberate re-key remove the stale .tovio/relay-identity.der and re-clone from the trusted relay — or something is intercepting the connection. Do not work around it by disabling verification; there is deliberately no flag for that.