Hi again,

I just noticed that the bottom of that reviews link includes a reference to 
this one: 
https://reviews.freebsd.org/R11:52e0c40367d3ebd09ab7169e025c37fbf70b8dee
and that restores the symlinks and bumps the port revision up to 2.

I've just updated my ports tree to catch that and rebuilt both 
security/ca_root_nss and mail/fetchmail and can (happily) confirm that this has 
fixed the problem for me.  So I guess that security/openssl31 is one of the 
ports that relies on the previous symlink.

Cheers,

Andrew



> On 9 Oct 2023, at 10:33, Andrew Reilly <[email protected]> wrote:
> 
> 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
> 

Reply via email to