Problème avec mail-receiver et certificat auto-signé ?

Soutien Installation
1

J’essaie de configurer la réception d’e-mails pour une instance Discourse auto-hébergée derrière un proxy inverse (http(s), SMTP). Domaine public : public.example.com, hôte derrière le proxy inverse : internal.example.com. J’ai suivi ce manuel mais je suis bloqué potentiellement à cause d’une erreur de certificat. J’utilise des certificats auto-signés pour le chiffrement interne entre le proxy inverse et les conteneurs Discourse. Le conteneur de messagerie semble avoir un problème avec le certificat auto-signé présenté par le conteneur Discourse, bien qu’il s’agisse d’un certificat chaîné. Qu’ai-je mal fait ou comment déboguer davantage le problème ?
La sortie du journal (pertinente) du conteneur de messagerie (./launcher logs mail-receiver) est :

21 mai 15:34:06 internal-mail-receiver postfix/qmgr[101]: BA3E16FDE7: from=<foo@example.com>, size=3836, nrcpt=1 (queue active)
<23>21 mai 15:34:06 receive-mail[113]: Recipient: nobody@public.example.com<19>21 mai 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>21 mai 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>'21 mai 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 partie (pertinente) du fichier de configuration mail-receiver.yml du conteneur de messagerie est :

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 clé privée ssl.key contient la clé privée du serveur (interne). Le certificat chaîné ssl.crt contient : certificat serveur + certificat CA (en tant que nouvel utilisateur, je ne suis pas autorisé à télécharger un fichier, je ne peux donc pas fournir le ssl.crt actuellement).

2

Les variables d’environnement smtpd_tls sont liées au serveur smtpd, c’est-à-dire la partie avec laquelle les autres serveurs de messagerie interagiront lors de la livraison des e-mails. Lorsqu’il essaie ensuite de livrer l’e-mail au point de terminaison handle_mail sur internal.example.com, quel que soit ce que Ruby utilise ne fait pas confiance à votre autorité de certification et, par conséquent, ne peut pas faire confiance à votre certificat auto-signé.

Pour que cela fonctionne, je pense que vous avez deux options. La première consiste à modifier mail-receiver.yml afin d’inclure votre certificat racine d’autorité de certification dans le conteneur, de sorte que Ruby lui fasse confiance. Je ne suis pas sûr à l’instant T à quoi cela ressemblerait, mais ce serait essentiellement la même chose que de faire confiance à une nouvelle AC sur n’importe quel système Linux, sauf via ce fichier yml de conteneur.

L’autre option consiste simplement à changer DISCOURSE_MAIL_ENDPOINT de internal. à public., ce qui le fera se connecter via votre proxy qui a probablement un certificat auquel il pourra faire confiance par défaut.

3

Merci pour votre aide, cela a fonctionné de cette façon !
(initialement, mon moi naïf supposait que toute communication entre les conteneurs se ferait directement entre les deux conteneurs de toute façon)

4

La communication se fait bien directement entre les deux conteneurs, c’est juste que vous avez configuré votre conteneur Discourse pour utiliser HTTPS avec un certificat auto-signé, ce qui modifie la méthode de communication requise.