Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comm.software.mailserver > #5608
| 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> |
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 | Next — Previous in thread | Find similar | Unroll 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