> 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.
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.
