'hostname "mail.domain.tld" stimmt nicht mit dem Serverzertifikat überein' :: SNI-Unterstützung? & wie man das Zertifikat aus dem Discourse-Container abfragt?

Beim Zugriff auf den POP3-Mailserver von einem anderen Server in unserer Domain erhalte ich eine Art Zertifikatsfehler. Die resultierende Meldung lautet: Job exception: hostname "mail.domain.tld" does not match the server certificate, liefert jedoch keine detaillierten Informationen zur Hostnamen-Abweichung innerhalb des Backtraces.

Erstens: In dieser Situation ist SNI erforderlich. Ein Systemadministrator hat darauf hingewiesen, dass Discourse möglicherweise nicht korrekt für die Verwendung von SNI konfiguriert ist, was zu dieser Fehlermeldung führt. Die Zertifikate wurden getestet und scheinen keine Probleme aufzuweisen.

Zweitens, nur um sicherzugehen, dass wir auf derselben Seite bezüglich des Debuggings sind: Wie sollte ich innerhalb des Discourse-Containers auf POP3 zugreifen (bzw. die Zertifikatanfrage und den Abgleich durchführen), um tatsächlich die Daten zu erhalten, die für den Zertifikatsabgleich verwendet werden? Ich möchte hier eine Plausibilitätsprüfung durchführen, um sicherzustellen, dass ich vergleichbare Größen vergleiche.

Ich habe nachgefragt, ob SNI auf dem Server deaktiviert werden kann, und die Antwort lautete, dass dies nicht möglich ist. Der Systemadministrator sagte:

Bitte beachten Sie, dass es keinen unterstützten Mechanismus zum Deaktivieren von Mail-SNI gibt. Sie müssen daher mit den Discourse-Entwicklern zusammenarbeiten, um dies zu unterstützen. Diese Seiten können Ihnen dabei helfen:

https://stackoverflow.com/questions/30244745/opensslsslsslcontext-sni-servername-cb-not-working
https://stackoverflow.com/questions/30238304/opensslx509certificate-showing-certificate-for-wrong-domain

Meine Empfehlung wäre, Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver anstelle von POP3 zu verwenden.

Ich bin wirklich froh, dass du das angesprochen hast. Ich habe diese Option nirgendwo gesehen und wünschte, ich hätte davon von Anfang an gewusst. Es wäre vielleicht eine gute Idee, diese Information in die Installationsanweisungen aufzunehmen oder sogar im app.yaml zu erwähnen, als etwas, das beim Einrichten des E-Mail-Bereichs zu berücksichtigen ist.

Ich habe dort auch um Input gebeten, um für mein Szenario etwas mehr Klarheit zu erhalten. Bitte fühl dich frei, dich einzubringen.

Tatsächlich ist dies im ersten Beitrag von Einrichtung von Antworten per E-Mail-Support verlinkt:

:bell: Alternativ kannst du, falls du GMail dafür nicht verwenden möchtest, deinen eigenen eingehenden E-Mail-Dienst mit Straightforward direct-delivery incoming mail einrichten.

Dein ursprünglicher Beitrag gibt nicht an, welche Dokumentation du befolgt hast, um in das POP3-Loch zu steigen. Wenn du jedoch den oben verlinkten offiziellen Leitfaden betrachtet hast, ist dieser dort seit dem 28. März verlinkt.

Ich habe in einem anderen Thema auf deine Antwort geantwortet, um vorzuschlagen, wie Adressen und Domains bei der Nutzung dieser Funktion strukturiert werden sollten.

Ich werfe meinen Hut in den Ring und bitte zudem höflich um Unterstützung für SNI. Postfix und Dovecot haben beide in den letzten Jahren die Unterstützung dafür hinzugefügt, und viele Menschen wie ich haben bereits umgestellt. Normalerweise ist Discourse bei solchen Themen bereits voraus, daher war ich ehrlich gesagt überrascht, dass dies auf der Roadmap fehlt.

Ich wollte nur kurz nachhaken, ob SNI überhaupt für die zukünftige Entwicklung geplant ist. Safari und Outlook unterstützen SNI bereits seit fast fünf Jahren. Es würde meine Serverkonfiguration für E-Mails erheblich vereinfachen, wenn ich einfach mein SNI verwenden könnte, anstatt auf einen einzigen E-Mail-Server zu verweisen.