On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cra...@gmx.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:
he...@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
>
>
>
>
>
>
--
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.
pgp8wdHnW3hk1.pgp
Description: PGP signature
