
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On Jul 19, 2025, at 19:55, Ross Finlayson <finlayson@live555.com> wrote:<br><div><blockquote type="cite"><br class="Apple-interchange-newline"><div><div>I don’t understand this ‘word salad’ (“system wide CA keystore”, etc.).<br></div></div></blockquote><div><br></div><div>On a Debian box, it means /etc/ssl/certs for the OS-installed files and /usr/local/share/ca-certificates/ for the locally-installed ones. These directories contain only the public halves of certs for the purposes of connection verification. Red Hattish boxes have a similar split, but differently named *because Linux*.</div><div><br></div><div>Regardless, this is distinct — on purpose! — from the private halves used by servers to encrypt messages, in /etc/ssl/private, read-only by root on Debian, which is what the OP is talking about, in part.</div><div><br></div><div>What the OP is _also_ talking about, however, is client-side certificates, which are used by the client for proving their identity to the server, in much the same way an SSH client logs in via authorized_keys.</div><div><br></div><div>These don’t go in _any_ of the above locations, and I’m not aware of any standard location for such certs; it’s typically handled on a per-application basis. They need to be writable by the regular user on generation, then readable on use. (Analogy: ~/.ssh/id_*) One logical location would be ~/.local/ssl/private, mirroring the /etc system-level scheme.</div><div><br></div><div>One of the problems client-side certs solves is that it distributes identity to the edge: each client can have its own key, and the server has a list of keys it trusts.</div><div><br></div><div>The standard web model you’ve mirrored with RTSPS is that the client trusts some list of CAs absolutely. If I create a self-signed CA signing certificate and install it in of the locations above, there is nothing restricting that key from signing a TLS connection claiming to be, let us say, <a href="http://live555.com">live555.com</a>. The browser trusts _anything_ a trusted CA signing certificate signs.</div><div><br></div><div>This is how those corporate IT snooping boxes work: they require the clients to have the middlebox’s CA cert installed, allowing it to decrypt the TLS for inspection while proxying it.</div><div><br></div><div>I cannot speak for the OP’s use case, but one possible use for getting all this right is to prevent the connection from being established in the presence of such a middlebox, because even if it can impersonate the server, it cannot impersonate the client without first being fed each client's key separately.</div></div></body></html>