[Live-devel] RTSPS and PKI

[Warren Young]

On Jul 19, 2025, at 19:55, Ross Finlayson <finlayson at live555.com> wrote:
> 
> I don’t understand this ‘word salad’ (“system wide CA keystore”, etc.).

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*.

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.

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.

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.

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.

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, live555.com <http://live555.com/>. The browser trusts _anything_ a trusted CA signing certificate signs.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20250720/8058b9df/attachment.htm>