Problem mit Mail-Empfänger und selbstsigniertem Zertifikat?

Installation
1

Ich versuche, eingehende E-Mails für eine selbst gehostete Discourse-Instanz hinter einem Reverse-Proxy (http(s), SMTP) einzurichten. Öffentliche Domain: public.example.com, Host hinter Reverse-Proxy: internal.example.com. Ich habe diese Anleitung befolgt, stecke aber möglicherweise aufgrund eines Zertifikatfehlers fest. Ich verwende selbstsignierte Zertifikate für die interne Verschlüsselung zwischen Reverse-Proxy und Discourse-Containern. Der Mail-Container scheint ein Problem mit dem selbstsignierten Zertifikat zu haben, das vom Discourse-Container präsentiert wird, obwohl es sich um ein verkettetes Zertifikat handelt. Was habe ich falsch gemacht oder wie kann ich das Problem weiter debuggen?
Die (relevante) Log-Ausgabe des Mail-In-Containers (./launcher logs mail-receiver) lautet:

May 21 15:34:06 internal-mail-receiver postfix/qmgr[101]: BA3E16FDE7: from=<foo@example.com>, size=3836, nrcpt=1 (queue active)
<23>May 21 15:34:06 receive-mail[113]: Recipient: nobody@public.example.com<19>May 21 15:34:06 receive-mail[113]: Failed to POST the e-mail to https://internal.example.com/admin/email/handle_mail: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate) (OpenSSL::SSL::SSLError)<19>May 21 15:34:06 receive-mail[113]:   /usr/lib/ruby/2.7.0/net/protocol.rb:44:in `connect_nonblock'
  /usr/lib/ruby/2.7.0/net/protocol.rb:44:in `ssl_socket_connect'
  /usr/lib/ruby/2.7.0/net/http.rb:1009:in `connect'
  /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
  /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
  /usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
  /usr/local/lib/site_ruby/mail_receiver/internal_mail_receiver.rb:43:in `process'
  /usr/local/bin/receive-mail:13:in `<main>'May 21 15:34:06 internal-mail-receiver postfix/pipe[112]: BA3E16FDE7: to=<nobody@public.example.com>, relay=discourse, delay=0.39, delays=0.19/0.01/0/0.2, dsn=4.3.0, status=deferred (temporary failure)

Der (relevante Teil der) Konfigurationsdatei mail-receiver.yml des Mail-Containers ist:

env:
  POSTCONF_smtpd_tls_key_file:  /ssl/ssl.key
  POSTCONF_smtpd_tls_cert_file:  /ssl/ssl.crt
  POSTCONF_smtpd_tls_security_level: may

  DISCOURSE_MAIL_ENDPOINT: 'https://internal.example.com/admin/email/handle_mail'

volumes:
  - volume:
      host: /var/discourse/shared/standalone/ssl
      guest: /ssl

Der private Schlüssel ssl.key enthält den privaten Schlüssel des (internen) Servers. Das verkettete Zertifikat ssl.crt enthält: Server-Zertifikat + CA-Zertifikat (als neuer Benutzer darf ich keine Datei hochladen, daher kann ich das ssl.crt derzeit nicht bereitstellen).

2

Die smtpd_tls-Umgebungsvariablen beziehen sich auf den smtpd-Server, d. h. den Teil, mit dem andere Mailserver bei der Zustellung von E-Mails interagieren. Wenn er dann versucht, die E-Mail an den handle_mail-Endpunkt auf internal.example.com zuzustellen, vertraut das, was auch immer Ruby verwendet, Ihrer Zertifizierungsstelle nicht und kann daher Ihrem selbstsignierten Zertifikat nicht vertrauen.

Damit dies funktioniert, gibt es meiner Meinung nach zwei Möglichkeiten. Die erste besteht darin, mail-receiver.yml zu ändern, um Ihr Root-CA-Zertifikat in den Container aufzunehmen, damit Ruby ihm vertraut. Ich weiß nicht auswendig, wie das aussehen würde, aber es wäre im Grunde dasselbe, wie wenn Ruby einem neuen CA auf jedem Linux-System vertrauen würde, nur eben über diese Container-YML-Datei.

Die andere Möglichkeit besteht darin, DISCOURSE_MAIL_ENDPOINT von internal. auf public. zu ändern, wodurch eine Verbindung über Ihren Proxy hergestellt wird, der vermutlich ein Zertifikat hat, dem er standardmäßig vertrauen kann.

2 „Gefällt mir“
3

Vielen Dank für Ihre Hilfe, es hat so funktioniert!
(Anfangs ging ich naiverweise davon aus, dass die gesamte Kommunikation zwischen den Containern direkt zwischen den beiden Containern stattfinden würde)

2 „Gefällt mir“
4

Die Kommunikation findet direkt zwischen den beiden Containern statt, nur dass Sie Ihren Discourse-Container für die Verwendung von HTTPS mit einem selbstsignierten Zertifikat konfiguriert haben, was die erforderliche Kommunikationsmethode ändert.

1 „Gefällt mir“
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.