> On Tue, 11 Nov 2025 11:34:41 +0100 W. Kosior via Replicant wrote: > > > Well, if you download the certificate file from [1], then your browser > > actually verifies the certificate chain used by the letsencrypt.org > > website. > > But in the particular case, the web browser (on Replicant) does not > have that certificate, i.e. it cannot verify the chain, right?
Yes, and I believe this is the reason A. F. Cano had to download the cert using a computer, as described in an earlier email. If Let's Encrypt had wanted to let users download the root cert without already having it, they could have done as you suggest: signed the cert file (for example using PGP) and served the file+signature over plain HTTP. But instead they explicitly require all connections to use HTTPS. I.e., the unencrypted http://letsencrypt.org:80 redirects to https://letsencrypt.org instead of serving anything meaningful. If you nonetheless desired to download a cert file or even a web page from https://letsencrypt.org on a device without the root cert, you'd have to first instruct your user agent (e.g., the web browser or a tool like wget) to ignore the lack of a valid verification chain. And of course, this is not what site owners intended users to do. > > [...] to verify that the mirror owner is not > > doing something nasty. However, when both the checksum and the file > > are served from the same server, the checksum brings little benefit. > > What about integrity checks? Are those useless? They are not useless, but they are usually performed on other layers, anyway. If you are downloading over HTTPS, you cannot realistically get a corrupted file due to a malformed network packet — such packet would get detected on the TLS layer. If you are downloading over plain HTTP or FTP, there's a very minor chance (something that might have happened like a dozen thousand times since the dawn of the TCP protocol) that a packet gets corrupted during transmission but both the TCP checksum and the link layer protocol checksum still match. In such case, you would indeed download a broken file. > Also why not put the ckecksums on different hosts too? Do you mean having the checksum served by every mirror? If so, what would be the benefit of that? Best Wojtek -- W. Kosior website: https://koszko.org/koszko.html fediverse: https://friendica.me/profile/koszko/profile PGP fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A On Tue, 11 Nov 2025 12:13:39 -0000 John via Replicant <[email protected]> wrote: > On Tue, 11 Nov 2025 11:34:41 +0100 W. Kosior via Replicant wrote: > > > Well, if you download the certificate file from [1], then your browser > > actually verifies the certificate chain used by the letsencrypt.org > > website. > > But in the particular case, the web browser (on Replicant) does not > have that certificate, i.e. it cannot verify the chain, right? > > > [...] to verify that the mirror owner is not > > doing something nasty. However, when both the checksum and the file > > are served from the same server, the checksum brings little benefit. > > What about integrity checks? Are those useless? > Also why not put the ckecksums on different hosts too? > _______________________________________________ > Replicant mailing list > [email protected] > https://lists.osuosl.org/mailman/listinfo/replicant
pgptvNhOcs4CT.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
