Change to installation of security/ca_root_nss seems to have broken my mail?

From: Andrew Reilly <areilly_at_bigpond.net.au>
Date: Sun, 08 Oct 2023 23:33:45 UTC
Hi all,

I've had security/openssl31 installed for many months, and all dependent ports rebuilt against it, (with ssl=openssl31 in DEFAULT_VERSIONS) so that I could keep an eye on what might have issues with it, assuming an
eventual change to the 3-series in base.  And maybe it's more secure, given that it's had a pile of extra work done to it, while 1.1.1... is in maintenance.  Up to this weekend, everything has been great.

One of the applications that I use that depends on openssl is mail/fetchmail, which I use to retrieve mail from my ISP's IMAP server at imap.telstra.com:993.

Coincident with updating the security/ca_root_nss port, fetchmail started to complain that the imap server was using a self-signed certificat in its chain:

Oct  7 09:09:52 zen fetchmail[3770]: Server certificate verification error: self-signed certificate in certificate chain
Oct  7 09:09:52 zen fetchmail[3770]: Missing trust anchor certificate: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
Oct  7 09:09:52 zen fetchmail[3770]: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details.
Oct  7 09:09:52 zen fetchmail[3770]: OpenSSL reported: error:0A000086:SSL routines::certificate verify failed
Oct  7 09:09:52 zen fetchmail[3770]: imap.telstra.com: SSL connection failed.

After some head-scratching, I rebuilt fetchmail manually so that it was configured to use the openssl1.1.1w in base, rather than the port, and now it works again.  I haven't been able to figure out why.

I've tried rebuilding openssl31 with all of the optional (deprecated) pieces turned on, on the suspicion that Telstra must be using something dodgy, but their certificate does not seem to have changed recently, and does
not look especially dodgy to me: it seems to be signed by the DigiCert Global CA.

Looking at the timing of the failure and what changed at that point, I can now see that it was not openssl31 as such, but security/ca_root_nss that changed, and it did not change by upstream version, just by port version,
due to a change in the way that it is installed: https://reviews.freebsd.org/D42045

Does anyone have any thoughts about why this change would have broken this very specific thing, and perhaps what I can do about it?

Cheers,

Andrew