Hi, seit gestern bekomme ich ständig eine merkwürdige Meldung von fetchmail. Ich habe SuSE 8.2 mit Postfix als MTA. Fetchmail habe ich als Cronjob eingerichtet mit den Parametern fetchmail -a -s -f /etc/fetchmailrc eingerichtet. Seit gestern abend wird nun jedes mal, wenn Fetchmail aufgerufen wird folgende Meldung per Mail an root geschickr: fetchmail: Server CommonName mismatch: *.securesites.com != server1.foo wobei "server1.foo" für einen von zwei Servern steht, bei denen mittels POP3 Mail abgeholt wird. Diese Meldung wird etwa 15 mal wiederholt. Mail wird aber trotzdem abgeholt. Starte ich Fetchmail manuell mit fetchmail -a -vvv -f /etc/fetchmailrc, so bekomme ich folgende Ausgabe fetchmail: 6.2.1 fragt ab server1.foo (Protokoll POP3) um Don 01 Mai 2003 11:02:50 CEST: Abfrage gestartet fetchmail: POP3< +OK Qpopper (version 4.0.5) at ferver1.foo starting. fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 0 fetchmail: POP3< EXPIRE 0 fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< X-MANGLE fetchmail: POP3< X-MACRO fetchmail: POP3< X-LOCALTIME Thu, 1 May 2003 03:00:53 -0600 fetchmail: POP3< STLS fetchmail: POP3< IMPLEMENTATION Qpopper-version-4.0.5 fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK STLS fetchmail: Herausgeber-Organisation: Equifax fetchmail: Unbekannter Herausgeber-CommonName fetchmail: Server-CommonName: *.securesites.com fetchmail: Server-CommonName stimmt nicht überein: *.securesites.com != server1.foo fetchmail: server1.foo-Schlüssel-Fingerabdruck: 9E:7C:65:CE:A6:0B:B0:8A:D9:1F:C5:C7:81:91:47:FF fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to get local issuer certificate fetchmail: Herausgeber-Organisation: Equifax fetchmail: Unbekannter Herausgeber-CommonName fetchmail: Server-CommonName: *.securesites.com fetchmail: Server-CommonName stimmt nicht überein: *.securesites.com != server1.foo fetchmail: Warnung: Server-Zertifikat-Überprüfung: certificate not trusted fetchmail: Herausgeber-Organisation: Equifax fetchmail: Unbekannter Herausgeber-CommonName fetchmail: Server-CommonName: *.securesites.com fetchmail: Server-CommonName stimmt nicht überein: *.securesites.com != server1.foo fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to verify the first certificate fetchmail: POP3> USER lists fetchmail: POP3< +OK Password required for lists. fetchmail: POP3> PASS fetchmail: POP3< +OK lists has 0 visible messages (0 hidden) in 0 octets. fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: Keine Post für lists bei server1.foo fetchmail: POP3> QUIT fetchmail: POP3< +OK Pop server at server1.foo signing off. Diese Meldungen würde ich so interpretieren, dass ein SSL-Zertifikat angelaufen ist. Dagegen spricht aber, dass eine ähnliche Meldung kommt, wenn ich Mail beim zweiten Server abhole, der bei einem völlig anderen ISP steht. fetchmail: 6.2.1 fragt ab server2.foo (Protokoll POP3) um Don 01 Mai 2003 11:12:05 CEST: Abfrage gestartet fetchmail: POP3< +OK Hello there. fetchmail: POP3> CAPA fetchmail: POP3< +OK Here's what I can do: fetchmail: POP3< STLS fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 10 fetchmail: POP3< PIPELINING fetchmail: POP3< UIDL fetchmail: POP3< IMPLEMENTATION Courier Mail Server fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK Begin SSL/TLS negotiation now. fetchmail: Herausgeber-Organisation: Thawte Consulting cc fetchmail: Herausgeber-CommonName: Thawte Server CA fetchmail: Server-CommonName: server2.foo fetchmail: server2.foo-Schlüssel-Fingerabdruck: 93:AB:79:5A:E3:FE:4F:57:EF:B0:75:F5:A8:D3:98:65 fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to get local issuer certificate fetchmail: Herausgeber-Organisation: Thawte Consulting cc fetchmail: Herausgeber-CommonName: Thawte Server CA fetchmail: Server-CommonName: server2.foo fetchmail: Warnung: Server-Zertifikat-Überprüfung: certificate not trusted fetchmail: Herausgeber-Organisation: Thawte Consulting cc fetchmail: Herausgeber-CommonName: Thawte Server CA fetchmail: Server-CommonName: server2.foo fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to verify the first certificate fetchmail: POP3> USER stefan.fricke fetchmail: POP3< +OK Password required. fetchmail: POP3> PASS fetchmail: POP3< +OK logged in. fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: Keine Post für stefan.fricke bei server2.foo fetchmail: POP3> QUIT fetchmail: POP3< +OK Bye-bye. fetchmail: 6.2.1 fragt ab server2.foo (Protokoll POP3) um Don 01 Mai 2003 11:12:09 CEST: Abfrage beendet Es wäre ja nicht auszuschließen, dass beide Zertifikate zum Monatsende abgelaufen sind, aber die Meltung tritt ja nicht seit Mitternacht auf (auch nicht seit Mitternacht UTC), sondern schon seit etwa 20:00 Uhr MESZ. Was kann ich clientseitig tun und wenn nichts, wie kann ich die Mail von Cron an root unterbinden? Stefan
* Stefan Fricke schrieb am Donnerstag, 2003-05-01:
seit gestern bekomme ich ständig eine merkwürdige Meldung von fetchmail. Ich habe SuSE 8.2 mit Postfix als MTA.
fetchmail: Server CommonName mismatch: *.securesites.com != server1.foo
Soll heißen, daß server1.foo ein SSL-Zertifikat benutzt, das für einen anderen Server ausgestellt wurde, nämlich securesites.com . Ich vermute jetzt einfach mal, daß "server1.foo" im Original kein Name innerhalb von securesites.com ist, denn dann hättest du das sicher auch unkenntlich gemacht. [...]
Es wäre ja nicht auszuschließen, dass beide Zertifikate zum Monatsende abgelaufen sind, aber die Meltung tritt ja nicht seit Mitternacht auf (auch nicht seit Mitternacht UTC), sondern schon seit etwa 20:00 Uhr MESZ.
Die Meldung ist ein Hinweis auf ein schwerwiegendes Problem. Diese Überprüfung, ob ein Zertifikat auch wirklich für den Server ausgestellt wurde, der es benutzt, schützt nämlich vor Angriffen, bei denen sich ein Server für einen anderen ausgibt.
Was kann ich clientseitig tun und wenn nichts, wie kann ich die Mail von Cron an root unterbinden?
Du kannst den Betreiber des Servers auf das Problem hinweisen. Vermutlich hat man dort vor kurzem auf ein neues Zertifikat umgestellt und auch gleich noch den offiziellen Servernamen geändert -- und betreibt den alten nur noch weiter, um Clients Zeit zur Umstellung zu geben. Diese Fehlermeldung zu unterdrücken, ist keine gute Idee, weil sie eben auf ein Sicherheitsproblem hinweist, und das in einer Umgebung, in der offensichtlich auf Sicherheit wert gelegt wird, denn sonst würde wohl kein SSL eingesetzt. Falls du dennoch darauf bestehst, füge deiner crontab oberhalb der Zeile, die fetchmal aufruft, die Zeile MAILTO="" hinzu. Für alle Jobs nach dieser Zeile kommen dann gar keine Benachrichtigungen mehr. -- Christian Ullrich Registrierter Linux-User #125183 "Remember: 'I am a person. I have a right to the ball.'"
participants (2)
-
Christian Ullrich
-
Stefan Fricke