On Thu, Apr 02, 2026 at 01:20:04PM +0000, Peter Gutmann wrote:
> Does Linux have an equivalent systemwide cert store that everything ends up
> using? That is, do people use the NSS cert store or the Chrome cert store as
> a de facto equivalent of CERT_SYSTEM_STORE_LOCAL_MACHINE or whatever?
Well, the Linux kernel unsurprisingly does not, and any packaging of the
TLS library's trust anchors is a per-"distro" decision.
But, also unsurprisingly, multiple linux distributions do bundle a set
of WebPKI trust-anchors, for example, on a Fedora 43 system:
$ /usr/bin/openssl version -d
OPENSSLDIR: "/etc/pki/tls"
$ rpm -qf /etc/pki/tls/cert.pem
ca-certificates-2025.2.80_v9.0.304-1.2.fc43.noarch
$ rpm -qi ca-certificates-2025.2.80_v9.0.304-1.1.fc43.noarch | tail -n4
Summary : The Mozilla CA root certificate bundle
Description :
This package contains the set of CA certificates chosen by the
Mozilla Foundation for use with the Internet PKI.
A call to SSL_CTX_set_default_verify_paths(3) on such a Fedora system,
leads to trust in the (currently 146) Mozilla WebPKI CAs.
A brower-like client (curl, wget, ...) that wants to be able to verify
ad hoc public HTTPS servers will typically trust those TAs. On Debian
systems, it may be linked with GnuTLS, but I assume the "distro" uses
the same or an equivalent trust store in that case.
At a previous employer, part of my job included maintaining custom
OpenSSL builds to be installed on the internal Debian systems, and in
those builds only the internal corporate CAs were trusted, the small set
of applications that were able and needed to directly reach external TLS
servers, had custom trust stores, possibly including the usual suspects
in some cases.
Postfix by default does not trust any CAs, either as a client or as a
server. The MTA operator gets to choose which, if any, non-default
trust anchors to add. SMTP defaults to unauthenticated opportunsitic
TLS. The built-in client access control is by SPKI fingerprint (which
also works with RFC7250 raw public keys), not by any name binding in
the client certificate.
But it is possible to pass CA-validated client certificate details to a
"policy service", which can then make custom access control decisions,
and it is in that context that the "clientAuth" issue shows up, when
in a peer-to-peer clique it is impractical for each server to be the
issuer of the client certificates, and the access granted is suitable
for a lightly validated remote peer.
The code necesary to opt-in to accepting "serverAuth" EKUs from remote
clients in that context was just released yesterday as part of Postfix
3.12-20260401.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
