fetchmail mit ssl

[Steffen Gumpert]

Hallo NG,

ich bin gerade dabei, fetchmail auf ssl umzustellen. Das klappte dank des
Wikis ganz gut. Leider bekomme ich beim Abholen der Mails folgende
Fehler:

fetchmail: Server certificate verification error: self signed certificate
in certificate chain
fetchmail: This means that the root signing certificate (issued for
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Premium Server
CA/emailAddress=premium-server@t
3074320008:error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed:s3_clnt.c:1168:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from x...@pop.gmx.net
fetchmail: Query status=2 (SOCKET)

Das analoge Problem liegt auch bei 1und1 vor.
Die certificate chains sind vollständig und gehasht. Mailpaket und Certs
sind aktuell. Wie kann ich fetchmail zum Laufen bekommen?

Vielen Dank für eure Hilfe, Steffen.

[Alex Busam]

hatte das gleiche Problem. Versuch es mal mit Rechten 777 im
Zertifikateverzeichnis...Bin gespannt, ob das bei Dir auch hilft!

Gruￜ
Alex

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com

[Steffen Gumpert]

> hatte das gleiche Problem. Versuch es mal mit Rechten 777 im
> Zertifikateverzeichnis...Bin gespannt, ob das bei Dir auch hilft!

nicht wirklich. Hätte mich auch gewundert, da fetchmail als root läuft.
Aber interessanterweise bekomme ich seitdem andere Fehlermeldungen:

fetchmail: Server certificate verification error: self signed certificate
in certificate chain

fetchmail: Missing trust anchor certificate: /C=ZA/ST=Western Cape/L=Cape

Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte

Premium Server CA/emailAddress=premium...@thawte.com
fetchmail: This could mean that the root CA's signing certificate is not
in the trusted CA certificate location, 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: OpenSSL reported: error:14090086:SSL

routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

fetchmail: SSL connection failed.
fetchmail: socket error while fetching from x...@pop.gmx.net
fetchmail: Query status=2 (SOCKET)

fetchmail: Server certificate verification error: unable to get local
issuer certificate
fetchmail: Broken certification chain at: /C=ZA/ST=Western Cape/L=Cape

Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte

Premium Server CA/emailAddress=premium...@thawte.com
fetchmail: This could mean that the server did not provide the
intermediate CA's certificate(s), which is nothing fetchmail could do
anything about. For details, please see the README.SSL-SERVER document
that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not
in the trusted CA certificate location, 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: OpenSSL reported: error:14090086:SSL

routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

fetchmail: SSL connection failed.
fetchmail: socket error while fetching from x...@pop.1und1.com
fetchmail: Query status=2 (SOCKET)

Die certificate chains sind laut /var/install/bin/certs-show-chain
immernoch in Ordnung und gehasht.

Gruß, Steffen.

[Alex Busam]

Mir ist das in meinem Fall auch ein Rï¿œtsel. Allerdings deutet nun das
Verhalten bei Dir doch ebenfalls darauf hin, dass da vielleicht noch ein
anderer Prozess im Spiel ist, fï¿œr den die Rechte vorher nicht
ausgereicht hatten!? Wie waren die Rechte zuvor bei Dir?

[Steffen Gumpert]

> Mir ist das in meinem Fall auch ein Rätsel. Allerdings deutet nun das

> Verhalten bei Dir doch ebenfalls darauf hin, dass da vielleicht noch ein

> anderer Prozess im Spiel ist, für den die Rechte vorher nicht

> ausgereicht hatten!? Wie waren die Rechte zuvor bei Dir?

Das Verzeichnis 755 und die .pem 644. Die Links natürlich 777.
Ich bin ratlos. Die hashs der certs stimmen mit denen eines
funktionierenden Systems überein. Die chains sind auch vollständig.

VG, Steffen.

[Holger Bruenjes]

Hallo Steffen

Am 2013-12-31 15:41, schrieb Steffen Gumpert:

> Das Verzeichnis 755 und die .pem 644. Die Links natï¿œrlich 777.

> Ich bin ratlos. Die hashs der certs stimmen mit denen eines

> funktionierenden Systems ï¿œberein. Die chains sind auch vollstï¿œndig.

Die Verzeichnis und Dateirechte stimmen so schon, sind die 'crl'
aktuell?

10. Download revocation list(s)


Starte fetchmail im debug modus

in der einen Konsole

setup
4. Service administration
Mail Service
10. Goto mail tools
12. View fetchmail log file



in der anderen Konsole

/etc/init.d/mail -debug restart fetchmail




Holger

[Steffen Gumpert]

Am 31.12.2013, 16:35 Uhr, schrieb Holger Bruenjes <holgerb...@gmx.net>:

Hallo Holger,

die revocation list wurde erfolgreich aktualisiert.
> /etc/init.d/mail -debug restart fetchmail
liefert mehr output, läuft aber auf dasselbe Resultat hinaus:

fetchmail: 6.3.26 querying pop.gmx.net (protocol POP3) at Tue, 31 Dec 2013
17:24:29 +0100 (CET): poll started
fetchmail: Trying to connect to 212.227.17.169/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Premium Server CA
fetchmail: Subject CommonName: Thawte Premium Server CA

fetchmail: Server certificate verification error: self signed certificate
in certificate chain
fetchmail: Missing trust anchor certificate: /C=ZA/ST=Western Cape/L=Cape
Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte
Premium Server CA/emailAddress=premium...@thawte.com
fetchmail: This could mean that the root CA's signing certificate is not
in the trusted CA certificate location, 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: OpenSSL reported: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from x...@pop.gmx.net

fetchmail: 6.3.26 querying pop.gmx.net (protocol POP3) at Tue, 31 Dec 2013
17:24:29 +0100 (CET): poll completed
fetchmail: Merged UID list from pop.gmx.net: <empty>
fetchmail: Query status=2 (SOCKET)

fetchmail: 6.3.26 querying pop.1und1.com (protocol POP3) at Tue, 31 Dec
2013 17:24:28 +0100 (CET): poll started
fetchmail: awakened at Tue, 31 Dec 2014 17:24:28 (CET)
fetchmail: Trying to connect to 212.227.15.161/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: Thawte Consulting cc
fetchmail: Issuer CommonName: Thawte Premium Server CA
fetchmail: Subject CommonName: thawte Primary Root CA

fetchmail: Server certificate verification error: unable to get local
issuer certificate
fetchmail: Broken certification chain at: /C=ZA/ST=Western Cape/L=Cape
Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte
Premium Server CA/emailAddress=premium...@thawte.com
fetchmail: This could mean that the server did not provide the
intermediate CA's certificate(s), which is nothing fetchmail could do
anything about. For details, please see the README.SSL-SERVER document
that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not
in the trusted CA certificate location, 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: OpenSSL reported: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from x...@pop.1und1.com

fetchmail: 6.3.26 querying pop.1und1.com (protocol POP3) at Tue, 31 Dec
2013 17:24:28 +0100 (CET): poll completed
fetchmail: Merged UID list from pop.1und1.com: <empty>
fetchmail: Query status=2 (SOCKET)

Warum wird bei GMX ein self signed certificate bemängelt obwohl es bei
anderen läuft?
Bei 1und1 scheint fetchmail ein Zertifikat zu überspringen, obwohl die
chain lokal korrekt angezeigt wird ->
"starting at depth 2".

Gruss, Steffen.

[Holger Bruenjes]

Hkllo Steffen

Am 2013-12-31 17:37, schrieb Steffen Gumpert:
> Am 31.12.2013, 16:35 Uhr, schrieb Holger Bruenjes <holgerb...@gmx.net>:

>> /etc/init.d/mail -debug restart fetchmail

> liefert mehr output, lï¿œuft aber auf dasselbe Resultat hinaus:

>
> fetchmail: 6.3.26 querying pop.gmx.net (protocol POP3) at Tue, 31 Dec 2013
> 17:24:29 +0100 (CET): poll started

Wie hast Du die Parameter gesetzt

FETCHMAIL_1_SSL_PROTOCOL='tls1'
FETCHMAIL_1_SSL_TRANSPORT='yes'
FETCHMAIL_1_SSL_FINGERPRINT='02:F6:EE:E0:3C:13:9A:34:26:3A:F7:6C:62:C1:63:DC


Das habe ich fuer gmx

Holger

[Holger Bruenjes]

Hallo Steffen

Am 2013-12-31 17:37, schrieb Steffen Gumpert:

> Warum wird bei GMX ein self signed certificate bemï¿œngelt obwohl es bei
> anderen lï¿œuft?
> Bei 1und1 scheint fetchmail ein Zertifikat zu ï¿œberspringen, obwohl die

> chain lokal korrekt angezeigt wird ->
> "starting at depth 2".

Erneuer die doch nochmal alle

openssl s_client -connect pop.gmx.net:995 -showcerts


und dann daraus die einzelnen rauskopieren da sind 3 Stueck drin

Holger

[Steffen Gumpert]

Hallo Holger,

> FETCHMAIL_1_SSL_PROTOCOL='tls1'
> FETCHMAIL_1_SSL_TRANSPORT='yes'
> FETCHMAIL_1_SSL_FINGERPRINT='02:F6:EE:E0:3C:13:9A:34:26:3A:F7:6C:62:C1:63:DC

ich hatte bei PROTO "auto" stehen, aber auch mit "tls1" -> derselbe Fehler.
Sonst stimmt es überein.

Gruss, Steffen.

[Steffen Gumpert]

Am 31.12.2013, 18:01 Uhr, schrieb Holger Bruenjes <holgerb...@gmx.net>:

Hallo Holger,

> und dann daraus die einzelnen rauskopieren da sind 3 Stueck drin

dort habe ich sie her. Das root ca cert wird allerdings von GMX falsch
zurückgegeben. Es wurde von /var/install/bin/certs-show-chain bemängelt.
Ich hatte es mir dann direkt von Thawte 'runtergeladen.

Wie gesagt stimmen die hashs mit denen eines laufenden
Systems überein, also auch die Zertifikate.
Was hat es denn mit "unable to get local issuer certificate" auf sich?
Das klingt so, als ob ich noch etwas tun müsste.

Gruss, Steffen.

[Juergen Edner]

Hallo Steffen,

> fetchmail: 6.3.26 querying pop.gmx.net (protocol POP3) ...
> ...

> fetchmail: Missing trust anchor certificate: /C=ZA/ST=Western
> Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services
> Division/CN=Thawte Premium Server CA/emailAddress=premium...@thawte.com

die Meldung ist meines Erachtens eindeutig. Das besagte "Thawte Premium
Server CA"-Zertifikat fehlt auf Deinem Server.

> fetchmail: 6.3.26 querying pop.1und1.com (protocol POP3) ...

> fetchmail: Subject CommonName: thawte Primary Root CA
> fetchmail: Server certificate verification error: unable to get local
> issuer certificate

Das besagte "Thawte Primary Root CA"-Zertifikat fehlt auf Deinem Server.

> Warum wird bei GMX ein self signed certificate bemängelt obwohl es bei
> anderen läuft?

Es kann sein, dass es sich hierbei um einen Folgefehler handelt. Wenn du
die angesprochenen Zertifikate korrekt installierst sollte das Problem
behoben sein.

Gruß Jürgen
--
Mail: jue...@eisfair.org

[Juergen Edner]

Hallo Steffen,

> Was hat es denn mit "unable to get local issuer certificate" auf sich?
> Das klingt so, als ob ich noch etwas tun müsste.

die Meldung besagt, dass ein Zertifikat der Zertifikatskette nicht auf
dem lokalen Server gefunden wird. D.h. egal was Du vermeintlich geprüft
hast, eine Datei fehlt noch auf dem Server oder ist veraltet.

Siehe auch:
http://www.info.teradata.com/HTMLPubs/DB_TTU_14_00/index.html#page/Database_Management/B035_1100_111A/SSL_TLS_OPTIONS.108.34.html

[Steffen Gumpert]

Hallo Jürgen,

> Das besagte "Thawte Primary Root CA"-Zertifikat fehlt auf Deinem Server.

hier mal der output von /var/install/bin/certs-show-chain pop.gmx.net.pem:
*
| certificate: pop.gmx.net.pem (287988d1)
| subject : /C=DE/ST=Rhineland-Palatinate/L=Montabaur/O=1&1 Mail &
Media GmbH/CN=pop.gmx.net
| issuer : /C=US/O=Thawte, Inc./CN=Thawte SSL CA
|
+->| certificate: thawte.ca.pem (978601d0)
| subject : /C=US/O=Thawte, Inc./CN=Thawte SSL CA
| issuer : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
|
+->| certificate: thawte_Primary_Root_CA.pem (2e4eed3c)
| subject : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
| issuer : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
|
+-> end of chain!

Es ist alles da, oder? Die Links mit Namen der angegebenen Hashs
existieren in /usr/local/ssl/certs und die Dateien, auf die sie verweisen,
sind lesbar.

>> Warum wird bei GMX ein self signed certificate bemängelt obwohl es bei
>> anderen läuft?
>
> Es kann sein, dass es sich hierbei um einen Folgefehler handelt. Wenn du
> die angesprochenen Zertifikate korrekt installierst sollte das Problem
> behoben sein.

Was bedeutet denn "installieren"? Ich habe die Dateien gemäß Wiki angelegt,
den output von openssl in die Dateien kopiert und dann gehasht.

Mittlerweile habe ich mir damit geholfen, dass ich fetchmail ohne
"sslcertck"
aufrufe, damit ich wenigstens Mails lesen kann. Das ist aber nicht Sinn der
Sache und ich bin damit auch nicht glücklich...

Gruss, Steffen.

[Juergen Edner]

Hallo Steffen,

> hier mal der output von /var/install/bin/certs-show-chain
> pop.gmx.net.pem:

> ...

> Es ist alles da, oder? Die Links mit Namen der angegebenen Hashs
> existieren in /usr/local/ssl/certs und die Dateien, auf die sie verweisen,
> sind lesbar.

die Ausgabe sieht absolut korrekt aus. Dies lässt meines Erachtens
nur den Schluss zu dass zwar der User 'root' berechtigt ist die
Zertifikatsdateien zu lesen, nicht jedoch der User 'exim', unter dem
das Fetchmail-Programm ausgeführt wird.

Ich schicke Dir einmal eine modifizierte Skriptdatei per PM zu, mit
der Bitte die Prüfung der Zertifikatskette wie angegeben durchzuführen.

[Steffen Gumpert]

Hallo Jürgen,

> Ich schicke Dir einmal eine modifizierte Skriptdatei per PM zu, mit
> der Bitte die Prüfung der Zertifikatskette wie angegeben durchzuführen.

vielen Dank für das Script! Sieht allerdings nicht anders aus:

hades # su - exim -s /bin/sh -c "/var/install/bin/certs-show-chain --nogui

pop.gmx.net.pem"
*
| certificate: pop.gmx.net.pem (287988d1)
| subject : /C=DE/ST=Rhineland-Palatinate/L=Montabaur/O=1&1 Mail &
Media GmbH/CN=pop.gmx.net
| issuer : /C=US/O=Thawte, Inc./CN=Thawte SSL CA
|
+->| certificate: thawte.ca.pem (978601d0)
| subject : /C=US/O=Thawte, Inc./CN=Thawte SSL CA
| issuer : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
|
+->| certificate: thawte_Primary_Root_CA.pem (2e4eed3c)
| subject : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
| issuer : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
|
+-> end of chain!

Die Rechte an den .pem stehen aus lauter Verzweiflung schon länger auf
0x777.

Gruss, Steffen.

[Juergen Edner]

Hallo Steffen,
laut der Trace-Datei die Du mir zugesandt hast fehlt beim Abruf von
'pop.gmx.net' definitiv das Zertifikat mit dem Hash "98ec67f0"
(/usr/local/ssl/certs/98ec67f0.0), welches auf meinem Rechner nur
2 weitere Zertifikate erfordert, beim pop.gmx.net-Zertifikat jedoch
3 (!!) Zertifikate.

Dies habe ich zum Anlass genommen und die involvierten Zertifikate
einer genaueren Untersuchung unterzogen. Dabei habe ich heraus gefunden,
dass es zwei Zertifikate mit dem selben Betreff bzw. dem selben Hash
gibt und das folgende 'Thawte Primary Root CA'-Zertifikat mit dem

SHA1-Hash : 2e4eed3c
SHA1-Print: 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
Gültig bis: 16.07.2036

durch das folgende 'Thawte Primary Root CA'-Zertifikat ERSETZT werden muss:

SHA1-Hash : 2e4eed3c
SHA1-Print: 53:35:E9:6A:28:51:28:32:EC:CF:A6:ED:7D:24:36:23:17:D9:94:DB
Gültig bis: 30.09.2020

Das Zertifikat lässt sich von folgender Webseite herunter laden. Dort
findet sich auch weitere Informationen zu diesem Sachverhalt:
http://www.tbs-certificates.co.uk/FAQ/en/341.html

Wenn man abschließend noch die Hashes neu erzeugen lässt sollte auch das
certs-show-chain-Skript die gewünschte Zertifikatskette anzeigen und der
E-Mail-Abruf ohne Fehlermeldung funktionieren.

[Juergen Edner]

Hallo Steffen,
es muss natürlich heißen:

> ...

> durch das folgende 'Thawte Primary Root CA'-Zertifikat ERSETZT werden muss:
>
> SHA1-Hash : 2e4eed3c
> SHA1-Print: 53:35:E9:6A:28:51:28:32:EC:CF:A6:ED:7D:24:36:23:17:D9:94:DB

> Gültig bis: 30.12.2020
^^^^^^^^^^

[Steffen Gumpert]

Hallo Jürgen,

> durch das folgende 'Thawte Primary Root CA'-Zertifikat ERSETZT werden
> muss:
>
> SHA1-Hash : 2e4eed3c
> SHA1-Print: 53:35:E9:6A:28:51:28:32:EC:CF:A6:ED:7D:24:36:23:17:D9:94:DB
> Gültig bis: 30.09.2020

ich habe die Zertifikate ausgetauscht. Jetzt (und erst jetzt) bemängelt
das certs-show-chain-Skript das Fehlen von /usr/local/ssl/certs/98ec67f0.0
Mit dem "alten" root cert lief die chain durch. Jetzt:

*
| certificate: pop.gmx.net.pem (287988d1)
| subject : /C=DE/ST=Rhineland-Palatinate/L=Montabaur/O=1&1 Mail &
Media GmbH/CN=pop.gmx.net
| issuer : /C=US/O=Thawte, Inc./CN=Thawte SSL CA
|
+->| certificate: thawte.ca.pem (978601d0)
| subject : /C=US/O=Thawte, Inc./CN=Thawte SSL CA
| issuer : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA
|
+->| certificate: thawte_Primary_Root_CA.pem (2e4eed3c)
| subject : /C=US/O=thawte, Inc./OU=Certification Services
Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte
Primary Root CA

| issuer : /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting

cc/OU=Certification Services Division/CN=Thawte Premium Server
CA/emailAddress=premium...@thawte.com
|

+-> Error: file '/usr/local/ssl/certs/98ec67f0.0' missing!

Welches Zertrifikat verbirgt sich dahinter und wo kann ich es herbekommen?

Gruß, Steffen.

[Steffen Gumpert]

OK, ich habs bei Thawte gefunden. Mal schauen, obs klappt...

S.

[Steffen Gumpert]

Hallo Jürgen,

you made my day! Dank deiner Hilfe läuft jetzt fetchmail
wie es soll.
Die Tatsache, dass Thawte zwei primary root cas
publiziert, die obendrein auch noch denselben sha1-hash
liefern, ist schon seltsam.

Nochmal vielen Dank für deinen Einsatz!
Jetzt werde ich den Mailversand angehen ;-)

VG, Steffen.

[Steffen Gumpert]

Am 02.01.2014, 21:30 Uhr, schrieb Steffen Gumpert <se...@gmx.de>:

Hallo Jürgen,

> Jetzt werde ich den Mailversand angehen ;-)

mit einem gefaketen exim.pem (wozu braucht es das?)
klappt nun auch der Mailversand per ssl mit 1und1.
Nochmal vielen Dank!

VG, Steffen.

[Juergen Edner]

Hallo Steffen,

>> Jetzt werde ich den Mailversand angehen ;-)
>
> mit einem gefaketen exim.pem (wozu braucht es das?)
> klappt nun auch der Mailversand per ssl mit 1und1.
> Nochmal vielen Dank!

bei Verwendung des TLS-Protokolls kann der Server vom Client ein
Zertifikat anfordern. Aus diesem Grund muss zumindest eines angelegt
werden falls es angefordert wird.

[H. D. Oezbilen]

Hallo Juergen,

> bei Verwendung des TLS-Protokolls kann der Server vom Client ein
> Zertifikat anfordern. Aus diesem Grund muss zumindest eines angelegt
> werden falls es angefordert wird.

exim.pem kann ein Link sein? Oder muss zwingend, notwendig doch eine
Datei angelegt werden, kein Link?

Gruss
Derya

[Holger Bruenjes]

Hallo Derya

Am 2014-01-04 17:02, schrieb H. D. Oezbilen:

> exim.pem kann ein Link sein?

ja, der kann auf Dein Serverzertifikat zeigen.

Holger