On 2019-09-24, Anatoli <m...@anatoli.ws> wrote: > Hi All, > > I see for some time that the link to Cloudflare CDN is broken. > https://www.openbsd.org/ftp.html says it is > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/ but it gives 404. > > It looks like Cloudflare removed /pub/ and renamed to lowercase OpenBSD > so the link that works is https://cloudflare.cdn.openbsd.org/openbsd/.
That would be due to the origin server which the cloudflare CDN is pointed at. (The CDNs aren't "real" content servers, they are just caching proxies). If this is still happening, please show the output from ftp -o- https://cloudflare.cdn.openbsd.org/pub/OpenBSD/ and ftp -o- https://cloudflare.cdn.openbsd.org/openbsd/ so we can get a better idea which origin server it's using etc. > Also, the Fastly (CDN) mirror frequently (like half the times) gives > connection errors, at least using it from Latin America. The IPs I get > from different LA countries are 151.101.2.217 (Brazil) & 151.101.218.217 > (Argentina). ftp.openbsd.org works always so when I get errors with > Fastly, I switch to it and it works well (but slowly), or to Cloudflare > which works well too and it's fast (at the modified URL). Is https://openbsd.c3sl.ufpr.br/pub/OpenBSD/ any better for you? > The Fastly errors are of the form "connection closed at byte xxx", "ftp: > connect: operation timed out \n signify: gzheader truncated", something > like "no valid ip address found" and similar. Probably it's a faulty or > overloaded server serving some LA countries? Or a slow link between the CDN and the origin server, or maybe some other reasons. Personally I would normally only regard the CDNs as a fallback option if other ways to fetch the files are not working well .. > And right now I'm getting an invalid cert error for > https://firmware.openbsd.org. It resolves to 145.238.209.46 > (pond.obspm.bsdfrog.org) and 94.142.244.34. The certificate is only > valid for the following names: distfiles.bsdfrog.org, emma-en-quete.com, > ftp.fr.openbsd.org, pond.obspm.bsdfrog.org, pond.stats.bsdfrog.org, > portroach.openbsd.org, www.emma-en-quete.com. Not sure if it's a > configuration error of some mirror server or something else. > > I know that the firmware as well as all other files are checked with > signify so https is not strictly required for authenticity (though it > does for privacy) and I don't remember if this domain has ever worked > via https before, anyway just in case there's really some misconfiguration. It's tricky to arrange certificates for this (firmware.openbsd.org is served from multiple completely separate places, run by different people, so each instance would need a different key+certificate, and CA challenges can't be done over HTTP for this). There is a way it can be done via letsencrypt with DNS-01 challenges and distributing updated certificates to the various mirrors, but it's fiddly to set this up, and it can't be done with OpenBSD's acme-client, and doesn't really solve any problems.
