[Eisfair] Zertifikatsprobleme bei Fetchmail (doch noch nicht erledigt)

[Dirk Alberti]

Hallo zusammen,

es geht weiter... :-(

Nachdem ich es wieder am laufen hatte (Dank an Marcus und Jürgen) nach 
löschen und Neu-Abarbeitung der ganzen Zertifikate, Fetchmail rief auch 
wieder die Mails ab, bekam ich dann vorgestern eine Email vom Server mit 
diesem Inhalt:



unable to load CRL
3073558152:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: X509 CRL
unable to load CRL
3073590920:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: X509 CRL
Cannot open a0006401c16a3f: Permission denied
Cannot open a0006501c16a42: Permission denied
Cannot open a0006601c16b37: Permission denied
Cannot open a0006701c16ae1: Permission denied
Cannot open a0006801c16b19: Permission denied
Cannot open a0006901c16b1c: Permission denied

...und noch ca. 100 gleichartige Zeilen...

Das sah für mich nach Problemen mit der CRL aus, also gleich mal im Certs-Setup den Punkt 8 "Update revocation list(s)" durchgeführt, was auch auf der Konsole mit diesen Zeilen endete. Die aufgeführten Dateien sahen für mich nach Hashes aus, allerdings sind sie in /var/certs/ssl/crl nicht zu finden.
Ok, nochmal Punkt 7 "Update certs/crl hashes" hinterher, beide Listen, Cerifikates und CRL. Ich dachte, da wird das "aufgeräumt".

Sicherheitshalber auch nochmal die CA-Bundles heruntergeladen "Download ca certificate bundle".

Irgendwann dann kamen wieder die altbekannten Mails mit dem Inhalt

fetchmail: awakened at Fri, 28 Apr 2017 12:24:38 (CEST)
fetchmail: Server certificate verification error: self signed certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
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.

...und so weiter.  :-(

Ich habes es dann, schon gernervt, mehrmals in unterschiedlicher Reihenfolge versucht, auch immer wieder die Hashes neu berechnen lassen, Zertifikatsketten der Mailkonten waren dann irgendwann mal wieder OK, aber ohne Erfolg für Fetchmail.

Das hatten wir ja erst. Also wieder alles aus /var/certs/ssl rausgeschmissen und wieder neu angefangen. Erst Certs, dann certs_dehydrated, dann Mail und Mail_addon_certificates durchgespielt und es lief dann irgendwann wieder.

Noch eine Frage:  Die oben erwähnten Dateien aus der Mail sind nirgends vorhanden. Ich vermute, dass es Hashes sind, die ich aus SSL mit gelöscht hatte. Muss ich bei so einer Komplett-Löschung noch woanders was entfernen, irgendeine Liste, wo Certs alles einträgt und die dann auch abgefragt wird?
Bei den Hashes steht ja "Permission denied", aber die sind ja überhaupt nicht vorhanden...


Und noch was: Gibt es eine einzuhaltende Reihenfolge, um die Zertifikate
einzurichten für die Zusammenarbeit Certs-Paket ->
Certs_dehydrated-Paket -> Mail-Paket (Fetchmail) -> Mail_addon_certificates?

Also Certs-Setup aufrufen und abspeichern, CA-Liste downloaden, CRL 
downloaden usw.

Certs frug aber nach zwischendurch mal nach einer eigenen CA, die es 
wohl einrichten wollte, Passwort, Land, Ort usw.   Aber das will ich 
doch gar nicht, dafür habe ich ja Certs_dehydrated. Irgendwie jagt da 
die Katze ihren eigenen Schwanz.  Vielleicht müsste das enger gekoppelt 
werden, entweder eigene CA oder Certs_dehydrated auswählbar?

Naja erstmal läuft es ja wieder...



Grüße

Dirk