Re: 6.4.1 won't fetch mail from gmail; 6.3.26 does - root CA's signing certificate is not in the trusted CA certificate location

Matthias Andree <[email protected]>
Newsgroups gmane.mail.fetchmail.user
Message-ID <[email protected]>
Am 01.10.19 um 13:19 schrieb [email protected]:
> 	Thanks.  A crontab job checks Slackware daily so my packages
> are never more than a day out-of-date.  It installs its certificates
> in /usr/share/ca-certificates/mozilla/ ; I put mine in /etc/ssl/certs/ ,
> link the certs in /usr/share/ca-certificates/mozilla/ to there.  I
> deleted all those links, made a new set, which seems to make fetchmail
> happy.  Perhaps Slackware's package manager didn't delete old certs
> because there were external links to them?
> 	Good to know the cert checks out for fetchmail now.  For all
> this time I thought the only relevant cert was the one gmail issued.
> How can I know which it uses?

fetchmail -v or fetchmail -v -v should show the issuer and subject
common names, or if you have broken-out certificate files (not one
bundle file, but 100+ individual files), you can probably use strace -e
trace=open or truss ... |& grep open    to trace the files that OpenSSL
opens.

Note OpenSSL needs symlinks on broken-out directories that an
OpenSSL-supplied script named c_rehash generates, it needs to be run on
/etc/ssl/certs.
OpenSSL will only attempt 12345678.0-like files, not the full .pem
files. Not sure if Slackware has update-ca-certificates or similar
scripts or post-install procedures that see to these.



_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.