Re: [gentoo-user] fetchmail + certs = problems

Heiko Zinke <mails@××××××.com> [10-10-03 22:01]:
> On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cramer@×××.de wrote:
> > Hi,
> >
> > fetchmail's log told me, that there is something wrong with the setup
> > of the certificats.
> >
> > In the log there is the following section
> >     fetchmail: Server certificate:
> >     fetchmail: Issuer Organization: Thawte Consulting cc
> >     fetchmail: Issuer CommonName: Thawte Premium Server CA
> >     fetchmail: Subject CommonName: pop.gmx.net
> >     fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6
> >     fetchmail: Server certificate verification error: unable to get local issuer certificate
> >     fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, 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.
> >     fetchmail: Server certificate:
> >     fetchmail: Issuer Organization: Thawte Consulting cc
> >     fetchmail: Issuer CommonName: Thawte Premium Server CA
> >     fetchmail: Subject CommonName: pop.gmx.net
> >     fetchmail: Server certificate verification error: certificate not trusted
> >     fetchmail: Server certificate:
> >     fetchmail: Issuer Organization: Thawte Consulting cc
> >     fetchmail: Issuer CommonName: Thawte Premium Server CA
> >     fetchmail: Subject CommonName: pop.gmx.net
> >     fetchmail: Server certificate verification error: unable to verify the first certificate
> >     fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
> >
> >
> > In beforehand I did the following:
>
> i did pretty much the same thing without success :(
>
> but the sslcertfile option in the default section of my .fetchmailrc finaly solved the problem:
> heiko@chiefwiggum:~> cat .fetchmailrc
> defaults
>     proto pop3
>     limit 0
>     mda "/usr/bin/procmail -d %T"
>     sslcertfile /etc/ssl/certs/ca-certificates.crt
>
> poll pop.1und1.de
>     user "xxx" keep ssl
>
> poll pop.gmx.net
>     user "xxx" keep ssl
>
>
> option sslcertfile in the fetchmail manpage and the update-ca-certificates manpage gave me the hint.
>
> cheers
> heiko
> >
> >
> >
> >
> >
> >
Hi Heiko,

looks good! ...and works!
Thank you for your help!

Best regards
mcc



>
> --
> This email is not and cannot, by its nature, be confidential. En route
> from me to you, it will pass across the public Internet, easily readable
> by any number of system administrators along the way. If you have received
> this message by mistake, it would be ridiculous for me to tell you not to
> read it or copy to anyone else, because, let's face it, if it's a message
> revealing confidential information or that could embarrass me intensely,
> that's precisely what you'll do. Who wouldn't? Likewise, it is superfluous
> for me to claim copyright in the contents, because I own that anyway, even
> if you print out a hard copy or disseminate this message all over the known
> universe.
> I don't know why so many corporate mail servers feel impelled to attach
> a disclaimer to the bottom of every email message saying otherwise. If
> you don't know either, why not email your corporate lawyers and system
> administrators and ask them why they insist on contributing so much to
> the waste of bandwidth? To say nothing of making the presence of your mail
> on public discussions or mailinglists of explicitly contratictory nature.
> May as well just delete it, eh? Oh, and this message is probably plagued
> with viruses as well.