Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Fetchmail und ssl

144 views
Skip to first unread message
Message has been deleted

Sven Hartge

unread,
Sep 24, 2014, 3:42:43 AM9/24/14
to
Volker Englisch <blac...@rabbit.inka.de> wrote:
> X-Post und F'up nach de.comm.software.mailserver

> Sven Hartge schrieb:
>> ,----
>> | poll pop.gmx.de with proto POP3
>> | user 'benutzer' password 'geheimsache' is benutzer
>> | ssl
>> | sslcertck
>> | sslcertpath /etc/ssl/certs
>> `----

> Ich habe eine ähnliche Ausgangssituation wie der OP. Nur, bei mir
> klappt das so wie oben angegeben nicht...

> | $ cat .fetchmailrc
> | poll securepop.t-online.de proto pop3
> | user "xxxx...@t-online.de" password "geheim" is xxxxx here
> | ssl
> | sslcertck
> | sslcertpath ./certs

> | $ ls -l certs
> | lrwx------ 1 xxxxx xxxxx 25 24 Sep 08:01 0a4fc9e9.0 -> securepop.t-online.de.pem
> | -rw------- 1 xxxxx xxxxx 6428 28 Aug 18:33 securepop.t-online.de.pem

Ja. Weil du dort die Root-CA-Zertifikate brauchst und _nicht_ das
Server-Zertifikat.

> | $ fetchmail
> | fetchmail: Fehler bei Server-Zertifikat-Überprüfung: self signed certificate in certificate chain
> | fetchmail: Das heißt, dass das Wurzelzertifikat (ausgestellt für /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2) nicht unter den vertrauenswürdigen CA-Zertifikaten ist, oder dass c_rehash auf dem Verzeichnis ausgeführt werden muss. Details sind in der fetchmail-Handbuchseite im bei --sslcertpath beschrieben.

Und die Fehlermeldung bestätigt dies.

> Im Netz finden sich tausende Anleitungen, aber irgendwie bekomme ich
> das mit dem "self signed certificate" nicht in den Griff...

Weil du es falsch machst, vermutlich weil die ganzen Anleitungen
Blödsinn erzählen, geschrieben von Leuten, die selbst keine Ahnung haben
und irgendwie glauben, etwas funktionierendes hingefrickelt zu haben.

Du musst dort einfach nur den Pfad zum Root-CA-Speicher deiner
Distribution eintragen. Bei Debian/Ubuntu ist dies z.B. /etc/ssl/certs.

S°

--
Sigmentation fault. Core dumped.

Volker Englisch

unread,
Sep 24, 2014, 6:20:45 AM9/24/14
to
Ad 24.09.14, Sven Hartge scribebat:
> Volker Englisch <blac...@rabbit.inka.de> wrote:
>> X-Post und F'up nach de.comm.software.mailserver
>
>> Sven Hartge schrieb:
>>> ,----
>>> | poll pop.gmx.de with proto POP3
>>> | user 'benutzer' password 'geheimsache' is benutzer
>>> | ssl
>>> | sslcertck
>>> | sslcertpath /etc/ssl/certs
>>> `----
>
>> Ich habe eine �hnliche Ausgangssituation wie der OP. Nur, bei mir
>> klappt das so wie oben angegeben nicht...
>
>> | $ cat .fetchmailrc
>> | poll securepop.t-online.de proto pop3
>> | user "xxxx...@t-online.de" password "geheim" is xxxxx here
>> | ssl
>> | sslcertck
>> | sslcertpath ./certs
>
>> | $ ls -l certs
>> | lrwx------ 1 xxxxx xxxxx 25 24 Sep 08:01 0a4fc9e9.0 -> securepop.t-online.de.pem
>> | -rw------- 1 xxxxx xxxxx 6428 28 Aug 18:33 securepop.t-online.de.pem
>
> Ja. Weil du dort die Root-CA-Zertifikate brauchst und _nicht_ das
> Server-Zertifikat.

Okay. Ich habe das Root-CA-Zertifikat der Telekom heruntergeladen und
unter /usr/local/share/certs gespeichert (FreeBSD). Dann in diesem
Verzeichnis einen c_rehash gemacht. Sieht dann so aus:

| $ ls -l
| lrwxr-xr-x 1 root wheel 30 24 Sep 12:14 /usr/local/share/certs/812e17de.0 -> Deutsche_Telekom_Root_CA_2.pem
| -r--r--r-- 1 root staff 1318 27 Jan 2014 /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
| -r--r--r-- 1 root staff 773328 31 Jan 2011 /usr/local/share/certs/ca-root-nss.crt

Wenn ich in der .fetchmailrc:

| sslcertpath /usr/local/share/certs

eintrage, bekomme ich den selben Fehler wie vorher. Trage och dort:

| sslcertfile /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem

ein, funktioniert es einwandfrei.

Gibts da noch einen logischen Grund, warum das mit "sslcertpath" allein
nicht funktioniert?

V*

Jakob Schürz

unread,
Sep 24, 2014, 9:13:55 AM9/24/14
to
Am 2014-09-24 08:13, schrieb Volker Englisch:
> X-Post und F'up nach de.comm.software.mailserver
>
> Sven Hartge schrieb:
>> ,----
>> | poll pop.gmx.de with proto POP3
>> | user 'benutzer' password 'geheimsache' is benutzer
>> | ssl
>> | sslcertck
>> | sslcertpath /etc/ssl/certs
>> `----
>
> Ich habe eine ï¿œhnliche Ausgangssituation wie der OP. Nur, bei mir
> klappt das so wie oben angegeben nicht...
>
> | $ cat .fetchmailrc
> | poll securepop.t-online.de proto pop3
> | user "xxxx...@t-online.de" password "geheim" is xxxxx here
> | ssl
> | sslcertck
> | sslcertpath ./certs
>
> | $ ls -l certs
> | lrwx------ 1 xxxxx xxxxx 25 24 Sep 08:01 0a4fc9e9.0 -> securepop.t-online.de.pem
> | -rw------- 1 xxxxx xxxxx 6428 28 Aug 18:33 securepop.t-online.de.pem
>
> | $ fetchmail
> | fetchmail: Fehler bei Server-Zertifikat-ï¿œberprï¿œfung: self signed certificate in certificate chain
> | fetchmail: Das heiï¿œt, dass das Wurzelzertifikat (ausgestellt fï¿œr /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2) nicht unter den vertrauenswï¿œrdigen CA-Zertifikaten ist, oder dass c_rehash auf dem Verzeichnis ausgefï¿œhrt werden muss. Details sind in der fetchmail-Handbuchseite im bei --sslcertpath beschrieben.
> | 3559:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:984:
> | fetchmail: SSL-Verbindung fehlgeschlagen.
> | fetchmail: Socket-Fehler beim Abholen von xxxx...@t-online.de@securepop.t-online.de
> | fetchmail: Abfragestatus=2 (SOCKET)
>
> Im Netz finden sich tausende Anleitungen, aber irgendwie bekomme ich
> das mit dem "self signed certificate" nicht in den Griff...

Ich musste den Port auch explizit in die .fetchmailrc reinnageln.

poll pop.gmail.com with
uidl
port 995
proto pop3
user ichbineinuser
password ichbineinpasswort
ssl
sslcertck
sslcertpath /etc/ssl/certs
is unix-user
nokeep

Bei gmx ging es ohne Port-Angabe.

lg jakob


--
http://xundeenergie.at
http://karriere.xundeenergie.at
http://jakobusschuerz.vemmaeurope.com
werts...@nurfuerspam.de

Helmut Hullen

unread,
Sep 24, 2014, 10:04:00 AM9/24/14
to
Hallo, Jakob,

Du meintest am 24.09.14:

> Ich musste den Port auch explizit in die .fetchmailrc reinnageln.

> poll pop.gmail.com with
> uidl
> port 995
> proto pop3
> user ichbineinuser
> password ichbineinpasswort
> ssl
> sslcertck
> sslcertpath /etc/ssl/certs
> is unix-user
> nokeep

> Bei gmx ging es ohne Port-Angabe.

Soweit ich das mitbekommen habe: bei einigen Providern steckt der Port
im URL, z.B. "securepop.example.com".

Viele Gruesse!
Helmut

Sven Hartge

unread,
Sep 24, 2014, 10:47:17 AM9/24/14
to
Volker Englisch <blac...@rabbit.inka.de> wrote:

> Okay. Ich habe das Root-CA-Zertifikat der Telekom heruntergeladen und
> unter /usr/local/share/certs gespeichert (FreeBSD). Dann in diesem
> Verzeichnis einen c_rehash gemacht. Sieht dann so aus:

> | $ ls -l
> | lrwxr-xr-x 1 root wheel 30 24 Sep 12:14 /usr/local/share/certs/812e17de.0 -> Deutsche_Telekom_Root_CA_2.pem
> | -r--r--r-- 1 root staff 1318 27 Jan 2014 /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
> | -r--r--r-- 1 root staff 773328 31 Jan 2011 /usr/local/share/certs/ca-root-nss.crt

> Wenn ich in der .fetchmailrc:

> | sslcertpath /usr/local/share/certs

> eintrage, bekomme ich den selben Fehler wie vorher. Trage och dort:

> | sslcertfile /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem

> ein, funktioniert es einwandfrei.

> Gibts da noch einen logischen Grund, warum das mit "sslcertpath" allein
> nicht funktioniert?

Hier wäre interessant, was strace (oder das *BSD dazu), um zu sehen,
welche Dateien fetchmail überhaupt versucht zu öffnen.

Volker Englisch

unread,
Sep 24, 2014, 12:14:05 PM9/24/14
to
Ad 24.09.14, Jakob Sch�rz scribebat:
> Am 2014-09-24 08:13, schrieb Volker Englisch:
>> X-Post und F'up nach de.comm.software.mailserver
>>
>> Sven Hartge schrieb:
>>> ,----
>>> | poll pop.gmx.de with proto POP3
>>> | user 'benutzer' password 'geheimsache' is benutzer
>>> | ssl
>>> | sslcertck
>>> | sslcertpath /etc/ssl/certs
>>> `----
>>
>> | $ fetchmail
>> | fetchmail: Fehler bei Server-Zertifikat-�berpr�fung: self signed certificate in certificate chain
>> | fetchmail: Das hei�t, dass das Wurzelzertifikat (ausgestellt f�r /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2) nicht unter den vertrauensw�rdigen CA-Zertifikaten ist, oder dass c_rehash auf dem Verzeichnis ausgef�hrt werden muss. Details sind in der fetchmail-Handbuchseite im bei --sslcertpath beschrieben.
>> | 3559:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:984:
>> | fetchmail: SSL-Verbindung fehlgeschlagen.
>> | fetchmail: Socket-Fehler beim Abholen von xxxx...@t-online.de@securepop.t-online.de
>> | fetchmail: Abfragestatus=2 (SOCKET)
>
> Ich musste den Port auch explizit in die .fetchmailrc reinnageln.
>
> poll pop.gmail.com with
> uidl
> port 995
> [...]

Hat leider in meinem Fall nichts geholfen.

V*

Volker Englisch

unread,
Sep 24, 2014, 12:12:43 PM9/24/14
to
Ad 24.09.14, Sven Hartge scribebat:
> Volker Englisch <blac...@rabbit.inka.de> wrote:
>
>> Okay. Ich habe das Root-CA-Zertifikat der Telekom heruntergeladen und
>> unter /usr/local/share/certs gespeichert (FreeBSD). Dann in diesem
>> Verzeichnis einen c_rehash gemacht. Sieht dann so aus:
>
>> | $ ls -l
>> | lrwxr-xr-x 1 root wheel 30 24 Sep 12:14 /usr/local/share/certs/812e17de.0 -> Deutsche_Telekom_Root_CA_2.pem
>> | -r--r--r-- 1 root staff 1318 27 Jan 2014 /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
>> | -r--r--r-- 1 root staff 773328 31 Jan 2011 /usr/local/share/certs/ca-root-nss.crt
>
>> Wenn ich in der .fetchmailrc:
>
>> | sslcertpath /usr/local/share/certs
>
>> eintrage, bekomme ich den selben Fehler wie vorher. Trage och dort:
>
>> | sslcertfile /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
>
>> ein, funktioniert es einwandfrei.
>
> Hier w锟絩e interessant, was strace (oder das *BSD dazu), um zu sehen,
> welche Dateien fetchmail 锟絙erhaupt versucht zu 锟絝fnen.

Here it comes... Kein Versuch, im certs-Verzeichnis 锟絙erhaupt etwas
锟絝fnen zu wollen.

| $ truss fetchmail | grep ^open
| open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory'
| open("/usr/local/lib/libintl.so.9",O_RDONLY,00) = 3 (0x3)
| open("/usr/local/lib/libiconv.so.3",O_RDONLY,027757763614) = 3 (0x3)
| open("/usr/lib/libopie.so.5",O_RDONLY,027757763614) = 3 (0x3)
| open("/var/run/ld-elf.so.hints",O_RDONLY,027757762570) = 3 (0x3)
| open("/lib/libcrypt.so.4",O_RDONLY,027757763614) = 3 (0x3)
| open("/lib/libmd.so.4",O_RDONLY,027757763614) = 3 (0x3)
| open("/lib/libkvm.so.4",O_RDONLY,027757763614) = 3 (0x3)
| open("/usr/lib/libcom_err.so.4",O_RDONLY,027757763614) = 3 (0x3)
| open("/usr/lib/libssl.so.5",O_RDONLY,027757763614) = 3 (0x3)
| open("/lib/libcrypto.so.5",O_RDONLY,027757763614) = 3 (0x3)
| open("/lib/libc.so.7",O_RDONLY,027757763614) = 3 (0x3)
| open("/etc/nsswitch.conf",O_RDONLY,0666) = 3 (0x3)
| open("/etc/pwd.db",O_RDONLY,00) = 3 (0x3)
| open("/etc/pwd.db",O_RDONLY,00) = 3 (0x3)
| open("/usr/share/locale/de_DE.ISO8859-1/LC_COLLATE",O_RDONLY,0666) = 3 (0x3)
| open("/usr/share/locale/de_DE.ISO8859-1/LC_CTYPE",O_RDONLY,0666) = 3 (0x3)
| open("/usr/share/locale/de_DE.ISO8859-1/LC_MONETARY",O_RDONLY,05024000000) = 3 (0x3)
| open("/usr/share/locale/de_DE.ISO8859-1/LC_NUMERIC",O_RDONLY,043) = 3 (0x3)
| open("/usr/share/locale/de_DE.ISO8859-1/LC_TIME",O_RDONLY,06) = 3 (0x3)
| open("/usr/share/locale/de_DE.ISO8859-1/LC_MESSAGES",O_RDONLY,0557) = 3 (0x3)
| open("/home/operator/.fetchmailrc",O_RDONLY,0666) = 3 (0x3)
| open("/etc/pwd.db",O_RDONLY,00) = 3 (0x3)
| open("/home/operator/.fetchids",O_RDONLY,0666) ERR#2 'No such file or directory'
| open("/home/operator/.netrc",O_RDONLY,0666) ERR#2 'No such file or directory'
| open("/home/operator/.fetchmail.pid",O_RDONLY,0666) ERR#2 'No such file or directory'
| open("/home/operator/.fetchmail.pid",O_WRONLY|O_CREAT|O_EXCL,0666) = 3 (0x3)
| open("/etc/resolv.conf",O_RDONLY,0666) = 3 (0x3)
| open("/etc/hosts",O_RDONLY,0666) = 3 (0x3)
| open("/etc/services",O_RDONLY,0666) = 3 (0x3)
| open("/etc/hosts",O_RDONLY,0666) = 3 (0x3)
| open("/etc/services",O_RDONLY,0666) = 3 (0x3)
| open("/etc/services",O_RDONLY,0666) = 3 (0x3)
| open("/etc/services",O_RDONLY,0666) = 3 (0x3)
| open("/etc/services",O_RDONLY,0666) = 3 (0x3)
| open("/dev/crypto",O_RDWR,00) ERR#2 'No such file or directory'
| open("/dev/urandom",O_NONBLOCK|O_NOCTTY,0440) = 4 (0x4)
| open("/usr/local/share/locale/locale.alias",O_RDONLY,0666) = 4 (0x4)
| open("/usr/local/share/locale/de_DE.ISO8859-1/LC_MESSAGES/fetchmail.mo",O_RDONLY,027757736010) ERR#2 'No such file or directory'
| open("/usr/local/share/locale/de_DE.iso88591/LC_MESSAGES/fetchmail.mo",O_RDONLY,027757736010) ERR#2 'No such file or directory'
| open("/usr/local/share/locale/de_DE/LC_MESSAGES/fetchmail.mo",O_RDONLY,027757736010) ERR#2 'No such file or directory'
| open("/usr/local/share/locale/de.ISO8859-1/LC_MESSAGES/fetchmail.mo",O_RDONLY,027757736010) ERR#2 'No such file or directory'
| open("/usr/local/share/locale/de.iso88591/LC_MESSAGES/fetchmail.mo",O_RDONLY,027757736010) ERR#2 'No such file or directory'
| open("/usr/local/share/locale/de/LC_MESSAGES/fetchmail.mo",O_RDONLY,027757736010) = 4 (0x4)
| open("/usr/local/lib/charset.alias",O_NOFOLLOW,016) = 4 (0x4)

V*

Sven Hartge

unread,
Sep 24, 2014, 12:42:43 PM9/24/14
to
Volker Englisch <blac...@rabbit.inka.de> wrote:
> Ad 24.09.14, Sven Hartge scribebat:
>> Volker Englisch <blac...@rabbit.inka.de> wrote:

>>> Okay. Ich habe das Root-CA-Zertifikat der Telekom heruntergeladen und
>>> unter /usr/local/share/certs gespeichert (FreeBSD). Dann in diesem
>>> Verzeichnis einen c_rehash gemacht. Sieht dann so aus:
>>
>>> | $ ls -l
>>> | lrwxr-xr-x 1 root wheel 30 24 Sep 12:14 /usr/local/share/certs/812e17de.0 -> Deutsche_Telekom_Root_CA_2.pem
>>> | -r--r--r-- 1 root staff 1318 27 Jan 2014 /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
>>> | -r--r--r-- 1 root staff 773328 31 Jan 2011 /usr/local/share/certs/ca-root-nss.crt
>>
>>> Wenn ich in der .fetchmailrc:
>>
>>> | sslcertpath /usr/local/share/certs
>>
>>> eintrage, bekomme ich den selben Fehler wie vorher. Trage och dort:
>>
>>> | sslcertfile /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
>>
>>> ein, funktioniert es einwandfrei.
>>
>> Hier wäre interessant, was strace (oder das *BSD dazu), um zu sehen,
>> welche Dateien fetchmail überhaupt versucht zu öffnen.

> Here it comes... Kein Versuch, im certs-Verzeichnis überhaupt etwas
> öffnen zu wollen.

Kennt deine Version das überhaupt?

strings `which fetchmail` | grep ssl

ergibt was?

> | open("/home/operator/.fetchmailrc",O_RDONLY,0666) = 3 (0x3)

Du hast schon die richtige Datei mit den Optionen versehen, ja? (Ich
frage nach, weil mir das schon oft genug passiert ist, dass ich die
falsche Konfig angepasst habe.)

Was passiert, wenn du die Option "--sslcertpath" mal an der
Kommandozeile mit übergibst beim truss-Aufruf? Ändert sich was? Du
könntest fetchmail auch einmal mit "--verbose" starten. Vielleicht ist
das erhellend.

Matthias Andree

unread,
Sep 24, 2014, 6:26:14 PM9/24/14
to
Am 24.09.2014 um 18:12 schrieb Volker Englisch:
> Ad 24.09.14, Sven Hartge scribebat:
>> Volker Englisch <blac...@rabbit.inka.de> wrote:
>>
>>> Okay. Ich habe das Root-CA-Zertifikat der Telekom heruntergeladen und
>>> unter /usr/local/share/certs gespeichert (FreeBSD). Dann in diesem
>>> Verzeichnis einen c_rehash gemacht. Sieht dann so aus:
>>
>>> | $ ls -l
>>> | lrwxr-xr-x 1 root wheel 30 24 Sep 12:14 /usr/local/share/certs/812e17de.0 -> Deutsche_Telekom_Root_CA_2.pem
>>> | -r--r--r-- 1 root staff 1318 27 Jan 2014 /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
>>> | -r--r--r-- 1 root staff 773328 31 Jan 2011 /usr/local/share/certs/ca-root-nss.crt
>>
>>> Wenn ich in der .fetchmailrc:
>>
>>> | sslcertpath /usr/local/share/certs
>>
>>> eintrage, bekomme ich den selben Fehler wie vorher. Trage och dort:
>>
>>> | sslcertfile /usr/local/share/certs/Deutsche_Telekom_Root_CA_2.pem
>>
>>> ein, funktioniert es einwandfrei.
>>
>> Hier w�re interessant, was strace (oder das *BSD dazu), um zu sehen,
>> welche Dateien fetchmail �berhaupt versucht zu �ffnen.
>
> Here it comes... Kein Versuch, im certs-Verzeichnis �berhaupt etwas
> �ffnen zu wollen.

Es gibt Default-Pfade einerseits und Default-Bundles andererseits.

Das Paket ca_root_nss, als Requisite f�r fetchmail, installiert letzeres
und einen Symlink in /etc/ssl/cert.pem. Das liest die OpenSSL auch
direkt beim Programmstart ohne besondere Konfiguration ein, und weil
dort das fragliche Wurzelzertifikat enthalten ist, braucht es auch keine
Zugriffe auf irgendwelche certs-Ordner mehr.

Hier brauche ich bei aktuellen FreeBSD-Ports jedenfalls keine
Verrenkungen auf FreeBSD zu machen, um mit GMX oder T-Online SSL/TLS
einschlie�lich Zertifikatpr�fung (sslcertck) zu haben, das funktioniert
ohne sslcert{path,file}-Optionen im rcfile "einfach so".

> $ fetchmail -v --sslcertck --ssl -p pop3 --uidl pop.gmx.net --user gibtsdochgarnicht
> Enter password for gibtsdoc...@pop.gmx.net:
> fetchmail: 6.3.26 querying pop.gmx.net (protocol POP3) at Thu Sep 25 00:24:07 2014: poll started
> Trying to connect to 212.227.17.169/995...connected.
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: T-Systems International GmbH
> fetchmail: Issuer CommonName: TeleSec ServerPass DE-1
> fetchmail: Subject CommonName: pop.gmx.net
> fetchmail: Subject Alternative Name: pop.gmx.net
> fetchmail: Subject Alternative Name: pop.gmx.de
> fetchmail: pop.gmx.net key fingerprint: 8A:B7:78:CF:0D:73:4E:EE:FF:EB:B8:C0:90:7D:46:56
> fetchmail: POP3< +OK POP server ready H migmx118 0Md7Nz-1XntZi3ALS-00IZg3
> fetchmail: POP3> CAPA
> fetchmail: POP3< +OK Capability list follows
...

> $ fetchmail -v --sslcertck --ssl -p pop3 --uidl securepop.t-online.de --user gibtsdochgarnicht
> Enter password for gibtsdoc...@securepop.t-online.de:
> fetchmail: 6.3.26 querying securepop.t-online.de (protocol POP3) at Thu Sep 25 00:24:33 2014: poll started
> Trying to connect to 194.25.134.46/995...connected.
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: T-Systems International GmbH
> fetchmail: Issuer CommonName: TeleSec ServerPass DE-2
> fetchmail: Subject CommonName: securepop.t-online.de
> fetchmail: Subject Alternative Name: securepop.t-online.de
> fetchmail: Subject Alternative Name: popmail.t-online.de
> fetchmail: Subject Alternative Name: pop-mail.t-online.de
> fetchmail: Subject Alternative Name: secure-pop.t-online.de
> fetchmail: Subject Alternative Name: multipop.t-online.de
> fetchmail: Subject Alternative Name: pop.t-online.de
> fetchmail: securepop.t-online.de key fingerprint: 3A:AF:21:D2:CB:14:32:A7:9C:C2:91:AA:3E:AF:D1:30
> fetchmail: POP3< +OK T-Online POP3 Server fpopd securepop.t-online.de ready
> fetchmail: POP3> CAPA
> fetchmail: POP3< +OK Ok

truss zeigt hier Zugriffe auf /etc/ssl/cert.pem an.

FreeBSD 9.3 und 10.0 amd64 in aktuellen Patchleveln, fetchmail-Paket
6.3.26_1, ca_root_nss-3.17.


Welche FreeBSD-Version hast Du?

Welche fetchmail und ca_root_nss-Version?

Hast Du OpenSSL aus Ports (oder per pkg) auch installiert?

H�ttest Du nach der Installation in /usr/local/share/certs auch
/usr/bin/c_rehash gemacht, oder gibt's noch ein /usr/local/bin/c_rehash,
das dann evtl. nicht zur /usr/lib/libssl.* passt?

Volker Englisch

unread,
Sep 25, 2014, 2:05:20 AM9/25/14
to
Ad 24.09.14, Sven Hartge scribebat:
> Kennt deine Version das �berhaupt?
>
> strings `which fetchmail` | grep ssl
>
> ergibt was?

| libssl.so.5
| ssl2
| ssl3
| ssl23
| [...]
| --sslproto force ssl protocol (SSL2/SSL3/TLS1)
| sslkey
| sslcert
| sslproto
| sslcertck
| sslcertfile
| sslcertpath
| sslcommonname
| sslfingerprint
| feature_options = ('pop3','imap','rpa','sdps','etrn','odmr','ssl','opie',)

>> | open("/home/operator/.fetchmailrc",O_RDONLY,0666) = 3 (0x3)

Jo, das passt.

Inzwischen klappts aber. Matthias hat mich auf den
(FreeBSD-spezifischen? Weg) gebracht - es fehlte nur ein Symlink an der
richtigen Stelle :-)

Danke auch Dir f�r die Geduld!

V*

Volker Englisch

unread,
Sep 25, 2014, 2:02:10 AM9/25/14
to
Ad 24.09.14, Matthias Andree scribebat:
> Das Paket ca_root_nss, als Requisite für fetchmail, installiert letzeres
> und einen Symlink in /etc/ssl/cert.pem. Das liest die OpenSSL auch
> direkt beim Programmstart ohne besondere Konfiguration ein, und weil
> dort das fragliche Wurzelzertifikat enthalten ist, braucht es auch keine
> Zugriffe auf irgendwelche certs-Ordner mehr.

Heureka! Das wars. Der Symlink hat gefehlt. Bei der Installation von
ca_root_nss habe ich wohl die Auswahl, den Symlink zu erstellen,
abgewählt. Oder das war in FreeBSD 7.4 noch der Default. ca_root_nss
aus den Ports neu installiert, und schon funktionierts.

Herzlichen Dank!

V*
0 new messages