On Jul 3, 2024, at 17:47, Philip Paeps <phi...@freebsd.org> wrote: > On 2024-07-04 01:27:03 (+0800), Mark Millard wrote: >> Bootstrapping pkg from >> pkg+https://pkg.FreeBSD.org/FreeBSD:14:aarch64/quarterly, please wait... >> Certificate verification failed for /CN=pkg.freebsd.org >> 0020616CE1680000:error:0A000086:SSL >> routines:tls_post_process_server_certificate:certificate verify >> failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1890: > > As far as I can tell, at the time of this writing, all fifteen > pkg.freebsd.org sites have the same certificate, and OpenSSL is happy with it. > >> Note the "pkg+https://";. >> >> I had separate problems yesterday that I side stepped by >> testing use of just "pkg+http://";, which worked. See: > > Use pkg+http. This is the default.
Hmm: # grep http /usr/src/usr.sbin/pkg/FreeBSD.conf.* /usr/src/usr.sbin/pkg/FreeBSD.conf.latest: url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest";, /usr/src/usr.sbin/pkg/FreeBSD.conf.quarterly: url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly";, Releases, snapshots, pkgbase, and artifacts all explicitly end up with https in /etc/pkg/FreeBSD.conf What the pkg program has as a default (if anything) is not in use for such. And I likely made all variants that I added as /usr/local/etc/pkg/repos/*.conf files based on copying /etc/pkg/FreeBSD.conf and then editing the copy, leaving the https in place. Again the .conf files matter, not the program defaults. > Packages are signed. Transport layer security does not provide any > additional security. (Anticipating the usual argument: it doesn't provide > privacy either - packages are trivially fingerprinted by file size.) I was just following the standard materials FreeBSD provides. I'd not have made the argument that you reference. I just figured FreeBSD was already using what folks more expert than I had classified as the thing to use for the most part. >> pkg with -d for the https context had its debug output >> reporting: >> >> * SSL certificate problem: certificate is not yet valid > > Does the system being bootstrapped have a real-time clock? Common causes for > this error are clocks set to 1970-01-01 or 2000-01-01. /var/log/messages confirms the time issue for my example boots that had the problem: it stayed back at Mar 16, not updating via ntpd as it normally does. (That date is probably from UFS. The system had not been booted since back then.) >> It happened to be using 204.15.11.66:443 for the https activity. > > For what it's worth: 204.15.11.66 = pkg0.tuk.freebsd.org. Yep, I'd found that. pkg0.tuk.freebsd.org is the expected place for my context. > r...@pkg0.tuk:~ # openssl x509 -noout -in > /etc/clusteradm/acme-certs/pkg.freebsd.org.crt -dates > notBefore=Jun 1 20:26:18 2024 GMT > notAfter=Aug 30 20:26:17 2024 GMT > Mar 16 is not in that range, for sure. Relative to the system, the certificate was in the future, matching the wording presented. It does seem that /etc/pkg/FreeBSD.conf should avoid the https notation so that it presents an appropriate default. Thanks much, Mark === Mark Millard marklmi at yahoo.com
