From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1P2Ugd-0003a7-SF for garchives@archives.gentoo.org; Sun, 03 Oct 2010 19:57:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E5B57E05E8; Sun, 3 Oct 2010 19:57:10 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by pigeon.gentoo.org (Postfix) with ESMTP id 98224E05E8 for ; Sun, 3 Oct 2010 19:57:10 +0000 (UTC) Received: from localhost (p4FF1CE0D.dip.t-dialin.net [79.241.206.13]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MWgo7-1PEFDC0VnX-00XS2y; Sun, 03 Oct 2010 21:57:09 +0200 Date: Sun, 3 Oct 2010 21:57:05 +0200 From: Heiko Zinke To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] fetchmail + certs = problems Message-ID: <20101003195705.GA31227@chiefwiggum.rabuju.com> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20101002103138.GA12555@solfire> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20101002103138.GA12555@solfire> User-Agent: Mutt/1.5.20 (2009-06-14) X-Provags-ID: V02:K0:JFN5McmgoqvzI2MU86A63DaBWX1wbPTdsPkB4A5Avwj rdLnhvN0D9d4KxFwZFRyGs7cwDooUlvLGredKguExMUBG8FmBj 9FYQp3SGmRGheznJitHxjNBVVvvgDXRuRxDJlxZizfURyO82/k i9+CXjhORsnAxwGGsmEzF4gSNZqO4bRI+zRWWCacEdbzmJffZF fzcAgTGo/c3hVIOifTW9Q== X-Archives-Salt: 201e2fbd-fb19-453d-a02a-7fde4caaac62 X-Archives-Hash: 68f86e9e5d8cd7eb6b3bc9c0ba3f5521 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cramer@gmx.de wrote: > Hi, >=20 > fetchmail's log told me, that there is something wrong with the setup > of the certificats. >=20 > 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=3DDE/ST=3DBayern/L=3DMunich/O=3DGMX GmbH/CN=3Dpop.gmx.net) is not in the = trusted CA certificate locations, or that c_rehash needs to be run on the c= ertificate directory. For details, please see the documentation of --sslcer= tpath 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 tru= sted > 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 th= e first certificate > fetchmail: Warning: the connection is insecure, continuing anyways. (= Better use --sslcertck!) >=20 >=20 > 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=20 defaults=20 proto pop3=20 limit 0 mda "/usr/bin/procmail -d %T" sslcertfile /etc/ssl/certs/ca-certificates.crt=20 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 >=20 >=20 >=20 >=20 >=20 >=20 --=20 This email is not and cannot, by its nature, be confidential. En route=20 =66rom me to you, it will pass across the public Internet, easily readable= =20 by any number of system administrators along the way. If you have received= =20 this message by mistake, it would be ridiculous for me to tell you not to= =20 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,=20 that's precisely what you'll do. Who wouldn't? Likewise, it is superfluous= =20 for me to claim copyright in the contents, because I own that anyway, even= =20 if you print out a hard copy or disseminate this message all over the known= =20 universe.=20 I don't know why so many corporate mail servers feel impelled to attach=20 a disclaimer to the bottom of every email message saying otherwise. If=20 you don't know either, why not email your corporate lawyers and system=20 administrators and ask them why they insist on contributing so much to=20 the waste of bandwidth? To say nothing of making the presence of your mail= =20 on public discussions or mailinglists of explicitly contratictory nature. May as well just delete it, eh? Oh, and this message is probably plagued=20 with viruses as well. --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyo4BEACgkQnf+eF7iECApviACfSOQHXnQiY/eHbGh5EVPOytRa tjsAoKocihtBoSo51hg+FHoKAQJxgBDo =niSZ -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR--