Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comm.software.mailserver > #5608

Re: fetchmail mit gmx

From Matthias Andree <matthias.andree@gmx.de>
Newsgroups de.comm.software.mailserver
Subject Re: fetchmail mit gmx
Date 2017-01-15 00:07 +0100
Message-ID <edvp98Fgp1dU1@mid.dfncis.de> (permalink)
References <o4otq7$1d69$1@adenine.netfront.net> <edfmkpFil3lU1@mid.dfncis.de> <o5596q$1osf$1@adenine.netfront.net>

Show all headers | View raw


Am 11.01.2017 um 13:42 schrieb Anton Blau:
> Am 08.01.2017 um 21:44 schrieb Matthias Andree:
>> Am 06.01.2017 um 21:13 schrieb Anton Blau:
>> Woher stammt das "sslcertpath"-Zeug? Wieso hat das so einen seltsamen
>> Pfad?
> 
> Die Dateien habe ich gem. der Anleitung unter
> http://www.gtkdb.de/index_36_2328.html hier angelegt.

Ich habe den Kainzbauer Anfang 2014 (in dem Fall die für CentOS 6) schon
gebeten, diese fetchmail-Anleitungen mit dem Fingerprint-Geraffel
verschwinden zu lassen. Ist nicht passiert, immerhin steht bei Dir noch
sslcertck dabei, das knallt Dir zum Glück gerade auf die Füße -
Kainzbauers Anleitung zur Fingerprint-Beschaffung geht unsichere Wege,
prüft nichts, ist umständlich und überflüssig.

Hast Du in der fetchmail-manpage nachgelesen, was die dort
abgeschriebenen Optionen im einzelnen tun? Sieht nicht so aus.

>> Sind die Mozilla-Zertifikate der Zertifizierungsstellen, oder zumindest
>> das "Deutsche Telekom Root CA 2", dort hinterlegt, die Fehlermeldung
>> bemängelt ja deren Fehlen.
> 
> Im sslcertpath /etc/ssl/fetchmaild/certs/ war das "Deutsche Telekom Root
> CA 2" bisher nicht enthalten, jedoch unter /etc/ssl/certs:

Da guckt fetchmail in Deiner Konfiguration aber nicht mehr, weil Du den
Pfad angibst.

> /etc/ssl/certs# ls Deutsche_Telekom_Root_CA_2.pem  -la
> lrwxrwxrwx 1 root root 65 Okt 20  2012 Deutsche_Telekom_Root_CA_2.pem ->
> /usr/share/ca-certificates/mozilla/Deutsche_Telekom_Root_CA_2.crt

Danach habe ich nicht gefragt, sondern nach "dort [= in
/etc/ssl/fetchmaild/certs/]".

> /etc/ssl# c_rehash
> Doing /usr/lib/ssl/certs
> WARNING: Skipping duplicate certificate ValiCert_Class_2_VA.pem.dpkg-new

Hier ist die Konfiguration bei einem Paket- oder Systemupgrade nicht
aufgeräumt worden.  Diese .dpkg-new sollten vermutlich die Basisdatei
mal ersetzen...

> WARNING: Skipping duplicate certificate ValiCert_Class_2_VA.pem.dpkg-new
> WARNING: Skipping duplicate certificate AddTrust_External_Root.pem
> WARNING: Skipping duplicate certificate AddTrust_External_Root.pem
> WARNING: Skipping duplicate certificate UbuntuOne-Go_Daddy_Class_2_CA.pem
> WARNING: Skipping duplicate certificate UbuntuOne-Go_Daddy_Class_2_CA.pem
> 
> Die doppelten Einträge wurden wohl vom System erstellt:
> 
> ls -la | grep ValiCert_Class_2_VA
> lrwxrwxrwx 1 root root        33 Jan 11 13:35 55a10908.0 ->
> UbuntuOne-ValiCert_Class_2_VA.pem
> lrwxrwxrwx 1 root root        33 Jan 11 13:35 bcdd5959.0 ->
> UbuntuOne-ValiCert_Class_2_VA.pem
> -rw-r--r-- 1 root root      1066 Mai 29  2013
> UbuntuOne-ValiCert_Class_2_VA.pem
> -rw-r--r-- 1 root root      1066 Jun 12  2012
> ValiCert_Class_2_VA.pem.dpkg-new
> 
> Kann ich die jeweils ältesten Dateien bedenkenlos löschen?

Nein, Du musst schon schauen, was davon relevant ist, und ggf. für den
richtigen Dateinamen sorgen.

Du kannst dpkg-reconfigure ca-certificates und ggf.
update-ca-certificates verwenden.  Siehe die zugehörige Dokumentation.

Back to de.comm.software.mailserver | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

fetchmail mit gmx Anton Blau <tony.blue@gmx.de> - 2017-01-06 21:13 +0100
  Re: fetchmail mit gmx Andreas Kohlbach <ank@spamfence.net> - 2017-01-06 17:03 -0500
    Re: fetchmail mit gmx Matthias Andree <matthias.andree@gmx.de> - 2017-01-08 21:44 +0100
  Re: fetchmail mit gmx Matthias Andree <matthias.andree@gmx.de> - 2017-01-08 21:44 +0100
    Re: fetchmail mit gmx Anton Blau <tony.blue@gmx.de> - 2017-01-11 13:42 +0100
      Re: fetchmail mit gmx Matthias Andree <matthias.andree@gmx.de> - 2017-01-15 00:07 +0100

csiph-web