Problema con mail-receiver e self-signed certificate?

Installazione
1

Sto cercando di configurare la ricezione di email per un’istanza discourse self-hosted dietro un reverse proxy (http(s), SMTP). Dominio pubblico: public.example.com, host dietro reverse proxy: internal.example.com. Ho seguito questo manuale ma sono bloccato potenzialmente a causa di un errore del certificato. Sto usando certificati autofirmati per la crittografia interna tra il reverse proxy e i container discourse. Il container di posta sembra avere un problema con il certificato autofirmato presentato dal container discourse, anche se è un certificato concatenato. Cosa ho sbagliato o come posso eseguire ulteriori debug del problema?
L’output del log (rilevante) del container di posta (./launcher logs mail-receiver) è:

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)

La parte (rilevante) del file di configurazione mail-receiver.yml del container di posta è:

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

La chiave privata ssl.key contiene la chiave privata del server (interno). Il certificato concatenato ssl.crt contiene: server-cert + ca-cert (come nuovo utente non mi è permesso caricare un file, quindi al momento non posso fornire l’ssl.crt).

2

Le variabili d’ambiente smtpd_tls sono relative al server smtpd, ovvero la parte con cui interagiranno altri server di posta durante la consegna delle email. Quando tenta quindi di consegnare l’email all’endpoint handle_mail su internal.example.com, qualunque cosa stia usando Ruby non si fida della tua autorità di certificazione e quindi non può fidarsi del tuo certificato autofirmato.

Affinché ciò funzioni, penso che tu abbia due opzioni. La prima è modificare mail-receiver.yml per includere il tuo certificato CA root nel container, in modo che Ruby si fidi di esso. Non sono sicuro al momento di come apparirebbe, ma sarebbe fondamentalmente lo stesso che far sì che Ruby si fidi di una nuova CA su qualsiasi sistema Linux, tranne che tramite quel file yml del container.

L’altra opzione è semplicemente cambiare DISCOURSE_MAIL_ENDPOINT da internal. a public., facendolo connettere tramite il tuo proxy che presumibilmente ha un certificato di cui si fiderà per impostazione predefinita.

2 Mi Piace
3

Grazie per il tuo aiuto, ha funzionato in quel modo!
(inizialmente, il mio ingenuo me stesso presumeva che tutta la comunicazione tra i container avvenisse direttamente tra i due container)

2 Mi Piace
4

La comunicazione avviene direttamente tra i due container, è solo che hai configurato il tuo container Discourse per utilizzare HTTPS con un certificato autofirmato, il che modifica il metodo di comunicazione richiesto.

1 Mi Piace
5

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