Zertifikatsfehler beim E-Mail-Hostname verursacht sidekiq-Warteschlangenüberlastung, schwere Website-Instabilität

[quote=“mstm, post:19, topic:225778”]zu etwas, das auf .aruba.it endet
[/quote]
Dies könnte bei der Suche nach dem richtigen helfen:

dig +short smtp.mydomain.info|xargs -n 1 nslookup|grep name=

3 „Gefällt mir“

Leider funktioniert es nicht, der Fehler ist derselbe:
SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

Mit Version 2.9.0.beta4 (0acbd63320) hat es funktioniert, kann ich downgraden?

Ich habe ein neues temporäres E-Mail-Konto mit Start-TLS-Unterstützung erstellt, ich hoffe, es wird vor der Veröffentlichung von 2.9.0.beta5 behoben sein.

2 „Gefällt mir“

Ich habe den Rat oben befolgt und den Hostnamen auf den Namen auf dem Zertifikat gesetzt.

Es ist erwähnenswert, dass in diesem Fall das Problem anscheinend nur nach einem vom Launcher initiierten Rebuild aufgetreten ist und nicht nur bei einem Upgrade. Vielleicht ein Problem mit den Launcher-Skripten?

2 „Gefällt mir“

Können Sie mir bitte sagen, wie Sie das gemacht haben?
Ich werde verrückt, ich kann den SMTP-Server nicht mit Port 25 oder 587 ohne SSL und TLS verwenden

Danke

1 „Gefällt mir“

Ich kann Ihnen dann möglicherweise nicht helfen, da meine Konfiguration kein TLS benötigt. Ich denke, das Einzige, was zu tun ist, ist entweder die Verwendung eines Drittanbieter-E-Mail-Anbieters, der gültige Zertifikate bereitstellt, oder auf eine Korrektur zu warten, die es ermöglicht, dieses Problem zu umgehen.

1 „Gefällt mir“

Haben Sie versucht, mit Richards dig-Befehl einen Hostnamen für Ihren SMTP-Server zu finden, für den er ein Zertifikat hat?

1 „Gefällt mir“

Meine ist auch ohne TLS und SSL :slight_smile:

1 „Gefällt mir“

Ähnliches Problem hier Can't Send Emails - #14 by sukria.
Hat sich etwas in der Basis-Image oder in einer externen Bibliothek oder Gem geändert?

6 „Gefällt mir“

Ja, das stimmt, es ist dasselbe Problem … es begann vor etwa zwei Wochen.

1 „Gefällt mir“

Können Sie beides versuchen?

DISCOURSE_SMTP_ENABLE_START_TLS: false
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
2 „Gefällt mir“

Das sind die ersten Dinge, die ich versucht habe, aber immer noch derselbe Fehler

SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
1 „Gefällt mir“

Hey, ich habe es mit beiden Optionen versucht. Es funktioniert immer noch nicht:

  DISCOURSE_SMTP_ADDRESS: REDACTED
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: REDACTED
  DISCOURSE_SMTP_PASSWORD: REDACTED
  DISCOURSE_SMTP_ENABLE_START_TLS: false           # (optional, default true)
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_AUTHENTICATION: "login"

Ich bekomme immer noch certificate verify failed (self signed certificate).

2 „Gefällt mir“

Für mich ist das seit langem ein blockierender Fehler …
Ich empfehle Ihnen, eine neue temporäre E-Mail-Adresse zu erstellen, die SMTP TLS unterstützt.

Könnte das mit diesem Gem zusammenhängen

4 „Gefällt mir“

Ich habe genau das gleiche Problem. Es begann gestern, als ich (durch Neuerstellung) auf 2.9.0.beta4 (a5779a7d0b) aktualisiert habe. Ich habe KEINE Änderungen an app.yml oder irgendetwas anderem vorgenommen. Nur eine Neuerstellung.

Ich habe jetzt über 1.300 fehlgeschlagene Jobs.

Ich sehe SSL-Fehler in den Protokollen (siehe unten für Screenshots) und frage mich, ob die Neuerstellung das DISCOURSE_SMTP_ENABLE_START_TLS-Flag plötzlich ignoriert?

Das ist es, was ich “immer” in meiner app.yml-Datei hatte: (wieder, es wurden keine Änderungen vorgenommen)

  DISCOURSE_SMTP_ADDRESS: 172.17.0.1
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false           # (optional, Standard true)

EDIT: Das sehe ich in den E-Mail-Protokollen für den Host (den E-Mail-Server). Die Fehlermeldungen sind neu und begannen nach der Neuerstellung.

Die letzte Nachricht bezüglich Discourse in den E-Mail-Protokollen vor der Neuerstellung:

May 23 17:16:02 localhost postfix/smtpd[5247]: connect from discourse-docker[172.17.0.2]
May 23 17:16:02 localhost postfix/smtpd[5247]: 0D803B67FB: client=discourse-docker[172.17.0.2]
May 23 17:16:02 localhost postfix/cleanup[5279]: 0D803B67FB: message-id=<topic/421230/2413438.f609f9d756c226a154de43f4@forums.jag-lovers.com>
May 23 17:16:02 localhost postfix/smtpd[5247]: disconnect from discourse-docker[172.17.0.2] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5

Der erste Eintrag in den E-Mail-Protokollen auf dem Server nach der Neuerstellung:

May 23 17:22:48 localhost postfix/smtpd[10929]: connect from discourse-docker[172.17.0.2]
May 23 17:22:48 localhost postfix/smtpd[10929]: SSL_accept error from discourse-docker[172.17.0.2]: -1
May 23 17:22:48 localhost postfix/smtpd[10929]: warning: TLS library problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1528:SSL alert number 42:
May 23 17:22:48 localhost postfix/smtpd[10929]: lost connection after STARTTLS from discourse-docker[172.17.0.2]
May 23 17:22:48 localhost postfix/smtpd[10929]: disconnect from discourse-docker[172.17.0.2] ehlo=1 starttls=0/1 commands=1/2

Nach dieser Zeit sehen die Einträge für Discourse in den E-Mail-Protokollen alle so aus.

Screenshots:

4 „Gefällt mir“

Ich habe versucht, eine Nachricht aus dem Discourse Docker-Container mit curl zu senden. Sobald ich sichergestellt hatte, dass Klartext-SMTP und Port 25 angegeben waren, konnte ich E-Mails über den Host problemlos senden:

$ cd /var/discourse/
$ sudo ./launcher enter app
x86_64 arch detected.
root@discourse-app:/var/www/discourse# curl smtp://172.17.0.1 --mail-from discourse@mydomain.com --mail-rcpt myname@gmail.com --upload-file README.md
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7077    0     0  100  7077      0   575k --:--:-- --:--:-- --:--:--  575k
root@discourse-app:/var/www/discourse#

Und so sah dieser Test in den E-Mail-Protokollen des Hosts aus:

May 24 16:53:49 localhost postfix/smtpd[25494]: connect from discourse-docker[172.17.0.2]
May 24 16:53:49 localhost postfix/smtpd[25494]: EB62CB5FCD: client=discourse-docker[172.17.0.2]
May 24 16:53:49 localhost postfix/cleanup[26008]: EB62CB5FCD: message-id=<>
May 24 16:53:49 localhost opendkim[1365]: EB62CB5FCD: can't determine message sender; accepting
May 24 16:53:49 localhost postfix/smtpd[25494]: disconnect from discourse-docker[172.17.0.2] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5

Da ich in meiner app.yml keine TLS und Port 25 angegeben habe und dies bis zum gestrigen Rebuild funktionierte, sieht es immer mehr danach aus, als würde das neueste Discourse meine SMTP-Konfiguration in app.yml ignorieren.

2 „Gefällt mir“

Bump, @pfaffman und/oder @codinghorror.

Glauben Sie, wir haben hier einen Fehler, oder etwas anderes?

1 „Gefällt mir“

@gunnar Ich habe deinen Beitrag hierher verschoben, da dies das E-Mail-Problem beschreibt, das du ansprichst.
Ich bin mir nicht sicher, ob der Fehler „Beitrag wurde bereits übernommen“ auch dadurch verursacht wird, aber die Details, die du zu deiner E-Mail gegeben hast, gehören zu diesem Problem.

2 „Gefällt mir“

Es kommt mir absurd vor, dass nach 30 Tagen immer noch dieses Problem besteht…
Ich musste meinen E-Mail-Anbieter wechseln, damit mein Forum wieder funktioniert.

1 „Gefällt mir“

Das ist frustrierend, aber es sieht für mich so aus, als ob ein Gem das Ignorieren ungültiger Zertifikate und/oder unverschlüsselter Transporte nicht mehr unterstützt. Es könnte einfach sein, dass die Zeiten, in denen man E-Mails auf diese Weise senden konnte, vorbei sind. Aber ich erlebe das Problem nicht selbst, daher habe ich nicht sorgfältig genug nachgesehen, um zu wissen, ob ich richtig liege.

2 „Gefällt mir“