Re: [Fetchmail-users] Certs again

[Matthias A. <mat...@gm...>]

Am 30.01.21 um 03:36 schrieb Gene Heskett:
> Greetings  Matthias Andree;
>> Gene,
>
>> I agree, but I am not (currently) aware of a function that lets me query
>> this information from OpenSSL in an easy manner. I'll go look again to
>> see if I find it now, or if such information was added...
>>
>> And that is why I was proposing ... to override it.
>>
>> Five minutes later, a hail to Joel for stackexchange.com, I figured this:
>>
>> https://stackoverflow.com/questions/4138139/how-to-find-out-the-path-for-openssl-trusted-certificate
>>
>> https://stackoverflow.com/questions/37035300/how-to-determine-the-default-location-for-openssl-cnf/54282217
>>
>> One is useful for me as a hint for having fetchmail print the
>> certificate paths used in verbose mode, and one is useful for you now to
>> check where your openSSL libraries go looking:
>>
>> /usr/bin/openssl version -a | grep OPENSSLDIR | cut -f2 -d\"
>>
>> /usr/local/bin/openssl version -a | grep OPENSSLDIR | cut -f2 -d\"
>
> gene@coyote:~$ /usr/bin/openssl version -a | grep OPENSSLDIR | cut -f2 -d\"
> /usr/local/ssl
> gene@coyote:~$ /usr/local/bin/openssl version -a | grep OPENSSLDIR | cut -f2 -d\"
> /usr/local/ssl
>
> So both of those are pointing to the newly built and
> installed openssl-1.1.1i version in /usr/local.

So I expect that /usr/local/ssl/certs (mind the trailing /certs) would
usually be the store for trusted certificates.

Either concatenated as cert.pem, or as individual files to be rehashed
into additional symlinks of the 98765432.0-style with the relevant
c_rehash program.

It appears Debian might had that typical package of Mozilla-curated
certificates, and I think it's called ca-certificates, but - not being a
Debian user - I think is still rather unlikely to install those certs
into /usr/local/ssl/certs.
Also I don't know how exactly the hash used in c_rehash changed over
OpenSSL versions.
It *has* changed across the 0.9.x -> 1.0.0 transition at the time, but I
haven't checked when else.

> Perhaps a missing make clean before the reconfigure, make,
> sudo make install to put it in /usr?

Overwriting /usr,is, um, daring.

I think Debian is normally rather good at integrating all its packages
well, and if you stomp an incompatible OpenSSL version over packaged
versions, this is outside how many other packages is this going to break?