Kein Mailversand nach Update der UCS Zertifikate

german

#1

Hallo,

ich habe etwa eine Woche vor dem Ablaufdatum (25.01.2017) der UCS Zertifikate, diese mit Hilfe dieses Artikels http://sdb.univention.de/content/15/268/en/erneuern-der-ssl_zertifikate.html erneuert. Nach dem Import des neuen Zertifikates in Thunderbird lief alles wie gewohnt. Bis gestern morgen (26.01.2016). Ab dann war es nicht mehr möglich Mails zu versenden, da keine Anmeldung mehr am smtp Server gelingt. Lediglich über das Webfrontend von Zarafa lassen sich noch Mails versenden. Das gilt für alle Benutzer. Wir setzen UCS 4.0-3 errata398 und Zarafa 7.1.14-51822 ein.

Der einzige Hinweis auf einen Fehler findet sich im server.log von Zarafa:

Disconnect from LDAP because search error Can't contact LDAP server

Die Verbindung zum LDAP funktioniert aber, wie ich mittels ldapsearch getestet habe.

Ich habe nach mehrstündiger Suche keinen offensichtlichen Fehler finden können. Wo muss ich suchen, bzw. Änderungen machen um das Problem zu beheben?

Gruß
Thomas


#2

Welche Zertifikate wurden erneuert? Nur der Zarafa Server? Wieviele Server gibt es da noch in der Umgebung und sind deren Zertifikate ggf. abgelaufen?


#3

Es wurden die SSL Zertifikate erneuert, wie in dem verlinkten Artikel der Supportdatenbank beschrieben. Weitere Server gibt es da nicht. Der Server auf dem der UCS läuft, beherbergt auch die anderen Dienste wie den Zarafa Server und Postfix. Das Webfrontend (Webaccess, Webapp) hat keine Probleme mit dem Versand von E-Mails.


#4

Hallo,

irgendwie verstehe ich das Problem nicht. Wenn Sie Serverzertifikate erneuern, müssen Sie an Clients überhaupt nichts tun, vorausgesetzt Sie haben dem Client das Zertifikat der Domain (siehe ucs-overview des Masters, “Wurzelzertifikat”) bekanntgemacht. Wie lautet denn die Fehlermeldung, die der Thunderbird beim Senden hochwirft?

Über welchen Port wird denn gesendet?

viele Grüße
Frank Greif.


#5

Was ich getan habe, steht schon im ersten Post. Die Fehlermeldung lautet: Login auf dem Server xxx fehlgeschlagen.

Den Zusammenhang zum Austausch des Zertifikates und dessen Ablauf habe ich hergestellt, da der Mailversand nach dem Austausch des Zertifikates funktioniert hat, bis das alte Zertifikat tatsächlich abgelaufen ist.

Gesendet wird über Port 25. Eine temporäre Änderung der Verbindungssicherheit von STARTTLS auf keine, bewirkt keine Änderung.


#6

Das dachte ich mir fast. Dieses wichtige Detail steht auch nicht im Post.
Auf Port 25 gibts kein AUTH (mehr), zumindest bei UCS 4.1 (siehe z.B. Kommentar 1 in [bug]43057[/bug]).
Das erklärt auch, warum der Versand vom Webfrontend geht. In den meisten Fällen funktioniert das Relay von localhost wegen der Defaults in mynetworks.

Ich würde den Versand über Port 587 versuchen.

Viele Grüße,
Dirk Ahrnke


#7

Ok. Vielen Dank für den Hinweis. Allerdings setzen wir bisher noch UCS 4.0-3 ein. Gilt in diesem Fall das gleiche?

Ein erster Test mit Port 587 im Thunderbird hatte keinen Effekt und resultiert in der gleichen Fehlermeldung.


#8

Ich hab schon lange kein 4.0.x mehr benutzt und der von mir verlinkte Bug zeigt, dass selbst ein Entwickler von Univention überrascht war, dass auf Port 25 keine Authentifizierung mehr geht.

Aus der Fehlermeldung geht für mich nicht klar genug hervor, ob der TB ein Problem mit dem Zertifikat hat oder ob die Authentifizierung fehlschlägt. Authentifizierungsprobleme sollten eigentlich in /var/log/mail.log zu sehen sein, was aber voraussetzt, das der Client überhaupt bis dorthin kommt.
Sie könnten ja mal die Prozedur der Konteneinrichtung inklusive Zertifikatsimport auf einer frischen Thunderbird-Instanz durchspielen.

Eine andere Möglichkeit wäre, zu prüfen, welches Zertifikat im Postfix hinterlegt ist. Testen kann man mit “openssl s_client …” (viele Fundstellen im Internet).
Die Zertifikatsdefinition steht in den UCR-Variablen “mail/postfix/ssl/*”. Den IT-Crowd Hinweis “did you try to switch it off and on again?” aus dem SDB-Artikel sollte man vielleicht auch noch mal erwähnen.

[quote]Alle Dienste, die SSL-Verschlüsselung benutzen, müssen neu gestartet werden.
Alternativ kann ein Neustart des Systems durchgeführt werden, wenn nicht bekannt ist, welche Dienste mit SSL in Verbindung stehen.[/quote]


#9

Ja, das geht mir genau so.

[quote=“ahrnke”]Den IT-Crowd Hinweis “did you try to switch it off and on again?” aus dem SDB-Artikel sollte man vielleicht auch noch mal erwähnen.
[/quote]
:wink:
Das ist bereits passiert. Was mich so verwirrt ist, das nach der Neuerstellung der Zertifikate am 10.1 bis zum 25.1 alles problemlos lief. Ab dem 26.1 war dann Ende, was genau mit dem Ablaufdatum des neuen Zertifikates zusammenfällt. Das kann natürlich Zufall sein, denn ich habe nach meiner Erinnerung auch die neuesten Errata Updates der Version 4.0-3 am 25.1 eingespielt.

Das hat leider auch nicht zum Erfolg geführt…

Wenn ich
openssl s_client -connect SERVER:25 -starttls smtp
oder
openssl s_client -connect SERVER:587 -starttls smtp
ausführe sieht für mich alles gut aus, bis auf das hier:
Verify return code: 21 (unable to verify the first certificate)

Wobei mir nicht ganz klar ist, ob das in diesem Zusammenhang ein Problem darstellt.

Diese Variablen sind in meiner UCS Installation nicht mit Werten gefüllt…

Weitere Interessantes Detail in diesem Zusammenhang ist, das Ausschalten der Verschlüsselung im Thunderbird zumindest lokale Mails versendet werden können. Mails nach extern werden dann weiterhin nicht verschickt. Wenn ich Port 25 nutze lautet die Fehlermeldung:
5.7.1: Relay access denied.
Nutze ich Port 587, lautet die Fehlermeldung:
5.7.0 Must issue a STARTTLS command first


#10

Hallo,

Das dürfen sie auch, man muß nur dann dort etwas reinschreiben, wenn man nicht die UCS-ausgestellten Zertifikate nehmen will.

Erscheinen da die richtigen Zertifikate? Im Zweifelsfall mit -showcerts ausgeben lassen.

heißt nur, daß s_client die Zertifikatskette nicht vollständig prüfen kann. Kann man vernachlässigen für das aktuelle Problem.

[quote]Nutze ich Port 587, lautet die Fehlermeldung:
5.7.0 Must issue a STARTTLS command first[/quote]
Das bedeutet, daß man STARTTLS verwenden muß. Welchen Fehler erhält man dann?

viele Grüße,
Frank Greif.


#11

Moin,

Ja.

Wenn ich STARTTLS nutze erhalte ich die gleiche Fehlermeldung, wie bei Port 25. Thunderbird meint, das das Login auf dem Server fehlgeschlagen ist. Versucht man das Passwort nochmals einzugeben, schlägt das auch fehl. Das Passwort ist aber definitiv korrekt. Wenn man das abbricht, wird ein unbekannter Fehler vom SMTP Server geliefert.

Gruß Thomas Heinrich


#12

Hallo,

Hundertprozentig sicher bin ich mir nicht, aber ich glaube mich zu erinnern, daß Thunderbird, wenn er einmal eine Zertifikatsausnahme für einen Host gesagt bekommen hat, danach nicht ein weiteres Mal fragt, auch wenn sich das Zertifikat ändert. Es kommt dann nur immer wieder der Paßwort-Prompt, mehr nicht. Das ist das Problem, wenn man anfängt, Host-Zertifikate manuell zu akzeptieren. Ich hatte ja bereits geschrieben, daß man das niemals braucht, wenn man dem Thunderbird einmal das Aussteller-Zertifikat bekannt gemacht hat.

Prüfen wir doch mal genau, was Thunderbird über unseren Host “weiß”. In Einstellungen -> Erweitert -> Zertifikate und dort die Tabelle “Zertifikate” aufschlagen. Ich weiß, diese Tabellen sind sehr unhandlich; mit etwas Aufwand kann man auch die entsprechenden Dateien im Profilverzeichnis auslesen; letztlich bleibt es umständlich auf eine andere Art.

[ul]
[li] Zuerst im Reiter “Andere”: steht da unser Zielhost drin? Wenn ja -> entfernen.[/li]
[li] im Reiter “Server”: steht da unser Zielhost drin? Zumindest in der Rubrik “(unbekannt)” darf er nicht stehen.[/li]
[li] im Reiter “Zertifizierungsstellen”: steht da die UCS-CA drin? Die UCS CA ist auf den Namen der Domäne registriert, sollte also leicht zu finden sein, auch wenn hier ein paar hundert CA’s drin stehen. Dies ist der einzige Eintrag, der benötigt wird. Wenn er fehlt: UCS CA Zertifikat vom Domain Master downloaden und im Thunderbird importieren.[/li][/ul]

Wenn bis hierhin alles in Ordnung ist und Thunderbird immer noch nach dem Paßwort fragt, würde ich als nächstes auf dem Server suchen, was sich verändert hat.

viele Grüße
Frank Greif.


#13

Guten morgen,

zuerst mal vielen Dank für die ausführliche Antwort.

Hier meine ich mich zu erinnern, dass Thunderbird erst nach dem löschen der Ausnahmen fragt, dies aber dann tut.

Dieses Verhalten konnte ich so nicht nachvollziehen. Nachdem ich das Root Zertifikat (UCS-CA) von unserem UCS heruntergeladen und im Thunderbird importiert habe, wollte Thunderbird beim nächsten Versuch eine Mail zu versenden wieder eine Ausnahme installieren.

[quote]
[ul]
[li] im Reiter “Server”: steht da unser Zielhost drin? Zumindest in der Rubrik “(unbekannt)” darf er nicht stehen.[/li]
[li] im Reiter “Zertifizierungsstellen”: steht da die UCS-CA drin? Die UCS CA ist auf den Namen der Domäne registriert, sollte also leicht zu finden sein, auch wenn hier ein paar hundert CA’s drin stehen. Dies ist der einzige Eintrag, der benötigt wird. Wenn er fehlt: UCS CA Zertifikat vom Domain Master downloaden und im Thunderbird importieren.[/li][/ul][/quote]
s.o. Die Ausnahme stand unter dem Reiter “Server” drin. Bei den “Zertifizierungsstellen” stand die UCS-CA nicht drin. Also habe ich diese importiert. Anschließend habe ich versucht eine Mail zu verschicken, mit dem gleichen negativen Ergebnis. Als nächstes habe ich die vorhandenen Ausnahmen im Reiter “Server” gelöscht und dann versucht eine Mail zu versenden. Dann bekam ich den Hinweis, dass ich eine Ausnahme hinzufügen soll. Aber auch dieser Schritt führte leider nicht dazu, das ich nun wieder Mails versenden kann. (Ich habe im Anhang noch Bilder der beiden Reiter)

Hier kämen dann nur das neu erstellte Zertifkat und die Errata der Version 4.0-3 in Frage. Wobei ich nicht wüsste, wo genau ich suchen sollte…





#14

Hallo,

hmm, wenn es trotzdem wieder nach einer Ausnahme fragt, dann ist das schon komisch. Es sieht für mich so aus, als würde der Server dem Thunderbird nicht das richtige Zertifikat präsentieren. Ich habe es gerade bei mir noch einmal gegengeprüft (auf einem UCS 4.0), ein DC, Postfix auf Port 587 mit Starttls, dann wirklich nur dessen CA in Thunderbird importiert -> und dann hat mich Thunderbird beim Verbinden überhaupt nicht wegen des Zertifikats gefragt.

Wenn Sie sich mit openssl s_client auf den Port 587 verbinden, wird doch das Zertifikat als Hexdump angezeigt, der Teil zwischen BEGIN CERTIFICATE und END CERTIFICATE. Könnten Sie diesen Block mitsamt der einrahmenden Minuszeichen mal in eine Datei speichern und dann darauf aufrufen

openssl x509 -text -noout -in dateiname

dann sehen Sie, ob es wirklich Ihr erneuertes Serverzertifikat ist, das da erscheint.

Mir ist noch etwas aufgefallen: Wenn Thunderbird die CA importiert, fragt er, wofür man dieser CA trauen will. Die Formulierung ist etwas unglücklich, so daß man sich auch vertun kann: “Identifizieren von Webseiten” meint nicht wirklich Webseiten, sondern es meint “Identifizieren von Servern” im allgemeinen. Und wenn man dieses Häkchen nicht setzt, wirkt es einfach nicht. Sie können das auch nachträglich noch setzen, der Knopf heißt “Vertrauen bearbeiten”.

viele Grüße
Frank Greif.


#15

[quote]Wenn Sie sich mit openssl s_client auf den Port 587 verbinden, wird doch das Zertifikat als Hexdump angezeigt, der Teil zwischen BEGIN CERTIFICATE und END CERTIFICATE. Könnten Sie diesen Block mitsamt der einrahmenden Minuszeichen mal in eine Datei speichern und dann darauf aufrufen

dann sehen Sie, ob es wirklich Ihr erneuertes Serverzertifikat ist, das da erscheint.[/quote]
Es ist definitiv das neue Zertifikat. Aber um sicher zu gehen, dass ich das richtig verstanden habe: Der Mailserver liefert beim Aufruf von

openssl s_client -connect ucs-master:587 -starttls smtp

das Zertifikat, das im Thunderbird auf dem Reiter “Server” zu finden ist. Diese habe ich verglichen und sie sind identisch.

Ja, ich habe erst mal alle Häkchen gesetzt um genau das zu verhindern.

Gruß
Thomas Heinrich


#16

Hallo,

Eigentlich glaube ich, daß es nun kein Zertifikatsproblem mehr sein kann. Sie haben sichergestellt:

[ul]
[li] daß keinerlei Zertifikatsausnahmen den Thunderbird durcheinanderbringen[/li]
[li] daß Thunderbird die CA des UCS Systems akzeptiert[/li]
[li] daß der Server wirklich das neu ausgestellte Zertifikat präsentiert[/li][/ul]

Momentaner Stand ist, daß Thunderbird sagt, das Paßwort sei falsch. Ich würde nochmal auf der Kommandozeile mit dem Server sprechen wollen, also wieder mit dem openssl s_client Befehl. Vorher bauen wir mal eine gültige Anmeldung zusammen. Dazu in einem extra Terminal diesen Befehl ausführen mit einem gültigen Nutzernamen samt Paßwort. Die kryptische Zeile müssen wir für nachher aufheben.

echo -ne '\000nutzername\000passwort' | base64
AG51dHplcm5hbWUAcGFzc3dvcnQ=

Und dann verbinden wir uns mittels openssl s_client wieder mit Port 587 unseres Servers. Dort geben wir ein

ehlo testhost

Die Ausgabe müßte etwa so aussehen:

ehlo testhost
250-der.host.name.de
250-PIPELINING
250-SIZE 40960000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Wichtig ist, daß er uns hier AUTH mit anbietet. Wenn nicht, müssen wir auf dem Server suchen warum. Wenn er AUTH PLAIN anbietet, können wir jetzt eingeben:

auth plain AG51dHplcm5hbWUAcGFzc3dvcnQ=

und das sollte der Server dann mit irgendeiner Art von Zustimmung beantworten. Wenn nicht: merken wir uns die genaue Zeit, wann wir getestet haben, es sucht sich dann auf dem Server einfacher.

viele Grüße
Frank Greif.


#17

Moin,

zunächst sorry für die späte Rückmeldung, ich habe doch glatt die zweite Seite im Thread übersehen… :frowning:

Dann habe ich das von Ihnen beschriebene ausprobiert und bekomme nach (den String habe ich natürlich durch meinen ersetzt)

auth plain AG51dHplcm5hbWUAcGFzc3dvcnQ=

das folgende:

535 5.7.8 Error: authentication failed: generic failure

Im Logfile des Servers findet sich nun in der /var/log/mail.info für diesen Zeitpunkt:

Feb  9 09:45:13 ucs-master postfix/smtpd[24183]: warning: SASL authentication failure: cannot connect to saslauthd server: Connection refused
Feb  9 09:45:13 ucs-master postfix/smtpd[24183]: warning: SASL authentication failure: Password verification failed
Feb  9 09:45:13 ucs-master postfix/smtpd[24183]: warning: unknown[172.22.23.10]: SASL plain authentication failed: generic failure

In der master.cf findet sich die entsprechende Zeile:

587       inet  n       -       n       -       -       smtpd  -o smtpd_sasl_auth_enable=yes -o smtpd_enforce_tls=yes

Ich habe an der Konfiguration des postfix keine wissentliche Änderung vorgenommen. Die Datei wurde auch laut Filesystem seit September 2015 nicht geändert. Ehrlich gesagt verstehe ich den Zusammenhang nicht richtig. Hat der Tausch des Zertifikates damit zu tun? Ich werde auf jeden Fall am kommenden Samstag den UCS auf die aktuelle Version hochziehen und auch Zarafa updaten. Ich habe ja noch die Hoffnung, das dieser Schritt evtl. hilfreich ist.

Interessant sind an dem ganzen noch die folgenden Fakten:
[ul][li]der obige Test mit Port 25 ergibt den gleichen Fehler[/li]
[li]Bei Nutzung von Port 25 und Deaktivierung der Verbindungsicherheit im Thunderbird, lassen sich lokale E-Mails problemlos versenden. Mails nach extern gehen dann aber weiterhin nicht.[/li][/ul]

Gruß
Thomas Heinrich


#18

Hallo,

wie es aussieht nähern wir uns der Lösung. Der saslauthd hat ein Problem.
Bitte erstmal nachsehen ob univention-sasl korrekt installiert ist. Wenn das ok ist, einfach mal den saslauthd neu starten, zur Sicherheit /var/log/auth.log prüfen ob er läuft und dann neu testen.

Viele Grüße,
Dirk Ahrnke


#19

Hallo,

das war es dann tatsächlich! Aus einem mir nicht bekannten Grund lief der saslauthd nicht mehr. Nach dem Start desselben läuft wieder alles wie gewohnt.
Ich habe mich bei der Ursachenforschung wohl zu sehr auf die Erneuerung Zertifikate gestürzt…

Vielen Dank an alle für die Hilfe und Unterstützung bei der Fehlersuche.

Gruß
Thomas Heinrich