Date: Tue, 26 Aug 2025 11:14:27 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@FreeBSD.org> To: Kyle Evans <kevans@FreeBSD.org> Cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: b88b0bb784c7 - main - caroot: Generate both trusted and untrusted Message-ID: <86ecsyv40c.fsf@ltc.des.dev> In-Reply-To: <dae48d1a-8209-452f-a988-be80d4326edc@FreeBSD.org> (Kyle Evans's message of "Mon, 25 Aug 2025 17:30:39 -0500") References: <202508252142.57PLgh5i068682@gitrepo.freebsd.org> <dae48d1a-8209-452f-a988-be80d4326edc@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kyle Evans <kevans@FreeBSD.org> writes: > That's great, thanks! I do notice one case if I run this today: > > deleted: trusted/Baltimore_CyberTrust_Root.pem > > This would traditionally get moved (by me) into untrusted/ so that `certc= tl rehash` > would do the right thing, but... This one got dropped from the Mozilla data. I haven't looked at their commit history so I don't know why. Seven other certificates moved from trusted to untrusted, two because they expired and the others because Mozilla switched their trust to =E2=80=9Cmust verify=E2=80=9D. See D52158. > I started typing this out and realized that we would have removed the con= tents of > /etc/ssl/certs before rehashing so that stale entries don't stick around,= and the source > certs in /usr/share/certs/trusted should be in ObsoleteFiles.inc and remo= ved by > `make delete-old`. We should probably call bankruptcy on the untrusted/ = dir entirely and > regenerate it completely from today's world with our next update, and upd= ate README in > secure/caroot to avoid recommending silly practices. I'm starting to think that we should actually not install untrusted certificates at all. They mean nothing to OpenSSL or any other TLS library, the only effect they have is to prevent certctl from adding the certificate to the trusted list if it shows up elsewhere, e.g. in ca_root_nss. But the more likely scenario is that a certificate is trusted in base (which is older) but no longer trusted in ca_root_nss (which is newer) and we don't get negative trust from ca_root_nss, so it will still be trusted until maybe an EN removes it from base. And then we have the case of the Baltimore CyberTrust Root above which Mozilla just dropped outright. With the current certctl implementation, it will remain trusted forever. This points toward the following: * certctl should stop ingesting /etc/ssl and construct a new trust store based solely on /usr/share/certs and /usr/local/share/certs, to avoid perpetuating certificates that once were trusted but no longer are * certctl should check the expiry date on trusted certificates and drop expired ones * we should stop shipping /usr/share/certs/untrusted * certctl should stop generating /etc/ssl/untrusted the way it does today * /etc/ssl/untrusted should only be used to store certificates which the admin has manually distrusted DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ecsyv40c.fsf>