Re: pkg_https:// failures related to, for example, "SSL certificate problem: certificate is not yet valid"

On Jul 3, 2024, at 17:47, Philip Paeps <philip@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.

> root@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