On Jul 19, 2025, at 19:55, Ross Finlayson <finlay...@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.
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
