E-Mail-Versand funktioniert nach dem Upgrade nicht

Unterstützung
1

Vor ein paar Tagen habe ich mein Discourse von einer Version, von der ich nicht genau weiß, welche es war (ich bin mir aber ziemlich sicher, dass es sich um eine 2.4 Beta handelte, auch wenn ich das nicht mit absoluter Sicherheit behaupten kann), auf die aktuelle Version 2.4.0.beta4 aktualisiert.

Kürzlich habe ich festgestellt, dass der E-Mail-Versand nicht mehr funktioniert; ich habe viele fehlgeschlagene Jobs in Sidekiq. Der Fehler bei allen diesen Jobs lautet: „Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: unsupported protocol“.

Meine E-Mail-Einstellungen verweisen auf einen alten Mailserver von mir (der ansonsten für alle Clients, unabhängig von deren Art, einwandfrei funktioniert), Port 587 mit einfacher Authentifizierung und enable_starttls_auto auf true gesetzt. Es hat seit der Einrichtung von Discourse Anfang dieses Jahres problemlos funktioniert, daher bin ich mir ziemlich sicher, dass es seit den letzten Updates nicht mehr funktioniert. Das Betriebssystem wurde in dieser Zeit weder geändert noch aktualisiert, und auch der Mailserver blieb unverändert.

Ich habe Discourse Version 2.4 gelesen, fand dort aber nichts, was mit E-Mail oder OpenSSL zu tun hat.

F1: Wo kann ich nachsehen, von welcher Version die letzte Aktualisierung und die davor durchgeführt wurden, damit ich die von mir verwendeten Versionen nachverfolgen kann?

F2: Wo finde ich genauere Zeitstempel dafür, wann die E-Mail-Jobs zu fehlschlagen begannen? Ich habe in Sidekiq auf einen Job geklickt, und dort steht, er sei vor zwei Tagen erstellt worden, was meiner Einschätzung nach mit dem Zeitpunkt der Aktualisierung übereinstimmt. Ich würde jedoch gerne verifizieren, dass E-Mail-Jobs davor nicht fehlgeschlagen sind.

F3: Vermutlich hat sich in der Version, die ich jetzt ausführe (im Vergleich zu der, die ich vorher nutzte), etwas in Bezug auf OpenSSL geändert. Was könnte das gewesen sein, und gibt es irgendwo eine Einstellung, die ich anpassen kann? Oder sollte ich versuchen, auf eine ältere Version zurückzugehen? Oder gibt es eine Möglichkeit, zusätzliche Informationen aus der Jobverarbeitung zu erhalten, damit ich sehen kann, welches Protokoll beanstandet wird?

2

Eines für dich, @gerhard :wink:

3

Können Sie versuchen, eine Verbindung zum SMTP-Server innerhalb des Docker-Containers herzustellen?

openssl s_client -connect <hostname>:<port> -starttls smtp

Funktioniert das? Welches Protokoll wird ausgewählt? Gegen Ende der Ausgabe sollten Sie so etwas wie folgt sehen:

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

oder wenn TLS 1.3 verwendet wird:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
4

Hier sind vier Durchläufe innerhalb von Docker:

root@foo-app:/# openssl s_client -connect mail.foo.com:587 -starttls smtp
CONNECTED(00000003)
139861698753664:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1922:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 320 bytes and written 353 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
root@foo-app:/#
root@foo-app:/#
root@foo-app:/# openssl s_client -connect mail.foo.com:587 -starttls smtp -tls1_1
CONNECTED(00000003)
140427988595840:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1922:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 320 bytes and written 174 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1568985038
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
root@foo-app:/#
root@foo-app:/#
root@foo-app:/# openssl s_client -connect mail.foo.com:587 -starttls smtp -tls1_2
CONNECTED(00000003)
140184139936896:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1922:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 320 bytes and written 258 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1568985044
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
root@foo-app:/#
root@foo-app:/#
root@foo-app:/# openssl s_client -connect mail.foo.com:587 -starttls smtp -tls1_3
CONNECTED(00000003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 262 bytes and written 278 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
root@foo-app:/#

Ich erhalte eine Fehlermeldung „protocol unsupported

5

Es wäre hilfreich, wenn jemand die Fragen 1 und 2 beantworten könnte. Ich muss prüfen, ob es eine Möglichkeit gibt, dies so schnell wie möglich auf eine ältere Version zurückzusetzen. Dafür muss ich wissen, welche die letzte funktionierende Version war.

6

Ich habe jetzt 3682 fehlgeschlagene E-Mail-Jobs in meiner Warteschlange. Bestätigungs-E-Mails für die Kontoerstellung werden nicht versendet, ebenso wenig wie andere E-Mails.

7

Bitte bearbeiten Sie /var/discourse/launcher und ersetzen Sie die Basis-Image-Version (image="discourse/base:2.0.20190906-0522") in Zeile 91 durch image="discourse/base:2.0.20190625-0946".

Erstellen Sie den Container anschließend neu und führen Sie die Befehle aus, die Sie unter E-mail sending not working after upgrade - #4 by rawtaz ausgeführt haben. TLS 1.3 wird nicht funktionieren, aber ist die Ausgabe der anderen Befehle ähnlich? Falls nein, was ist anders?

Könnten Sie mir im Privatnachrichten den Hostnamen des SMTP-Servers mitteilen, falls dieser öffentlich verfügbar ist?

8

Vielen Dank, @gerhard! Dein Vorschlag hat das Problem gelöst. Ich habe die Version des Basis-Images geändert, neu erstellt, und sofort begann das Forum, die Warteschlangen-E-Mails zu versenden (etwa 10.000 :D).

Ich habe die Befehle im Container erneut ausgeführt und erhalte andere (erfolgreiche) Ausgaben. Diese Ausgabe enthält Zertifikate und eine Menge anderer Dinge, also würde ich sie hier lieber nicht einfügen, es sei denn, du brauchst sie wirklich. Lass mich wissen, ob das ein Problem ist und du sie unbedingt benötigst.

Ich werde dir dir die Hostname des Mail-Servers per PN senden, damit du das Problem detaillierter untersuchen kannst – bitte behalte das für dich :slight_smile: Danke!

Edit: Ich markiere deinen letzten Beitrag als Lösung, da er das Problem behoben hat. Offensichtlich müssen wir jedoch herausfinden, was in dem neueren Basis-Image die Ursache dafür ist, damit man in Zukunft aktualisieren kann.

9

Ja, beim alten Image zu bleiben, ist keine langfristige Lösung. Dieses Image wird im Wesentlichen nicht mehr unterstützt, und es könnte zu Problemen kommen…

11

Dieses Problem ist ähnlich wie unter Email SSL Errors after Update to 2.4.0.beta4 beschrieben. Ich empfehle, Ihr SMTP auf TLSv1.2 zu aktualisieren und eine DH-Schlüsselgröße von mindestens 2048 Bit zu verwenden.

Als Workaround können Sie sed-Befehle zum run-Abschnitt am Ende von app.yml hinzufügen, um die folgenden beiden Einstellungen aus der Datei /etc/ssl/openssl.cnf zu entfernen.

MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2