Viktor Dukhovni:
> > On 19 May 2021, at 3:07 pm, Wietse Venema <wie...@porcupine.org> wrote:
> >
> >> Server haproxy.example.com:587 accepts public connections and proxies to
> >> submission.example.com:587
> >> Each server was given its own SSL cert (Let's Encrypt certbot).
> >
> > If the remote SMTP client negotiates a TLS handshake with
> > haproxy.example.com:587, then that remote SMTP client will not
> > negotiate a TLS handshake with submission.example.com:587.
>
> I haven't yet have cause to look closely at the Postfix "haproxy" code.
> So I could be mistaken, but at first blush it appears that Postfix
> handles the haproxy protocol *before* TLS, even in wrapper mode.
Haproxy can terminate TLS.
Wietse
> In which case the communication between haproxy and Postfix is always
> in the clear. And especially on port 587 (STARTTLS, not wrapper mode)
> the client will not initiate TLS until it gets through the initial ESMTP
> greeting and EHLO exchanges. So there's no role for any possible certificates
> on the haproxy side, it will remain a cleartext channel.
>
> With port 465, one might imagine haproxy terminating TLS, but it would then
> still have to communicate with Postfix in the clear, and then re-establish
> a new TLS connection, where it would be far simpler to just NOT terminate
> TLS on the haproxy side, and then possibly leverage client certs when/if
> desired, ...
>
>
> So bottom line, the OPs use-case of TLS on both haproxy and Postfix does
> not appear to make much sense...
>
> --
> Viktor.
>
>
