On Wed, May 19, 2021 at 05:13:32PM -0400, [email protected] wrote:
> > On 05-19-2021 5:06 pm, Viktor Dukhovni wrote:
> >
> > Why would the Postfix server have a "different certificate".
> > DON'T DO THAT.
>
> Something is being lost in translation here. How could you not have a
> different certificate?
You're not paying careful attention, so I'll have spell it out in gory
detail.
1. There's only one certificate chain:
End-Entity SAN: DNS:submission.example.com
2. This (same) certificate chain and associated private key is deployed
on all the backend servers that sit behind the load-balancer.
3. The hostname "submission.example.com" is a CNAME alias for the
proxy:
submission.example.com. IN CNAME haproxy.example.com.
haproxy.example.com. IN A 192.0.2.1
4. The proxy forwards port 587 (and perhaps also 465 and 25 as
needed) at the TCP layer to the backend servers encapsulated
in the haproxy protocol which carries remote client origin IP
metadata.
5. The proxy optionally forwards ports 80 and 443 (for "webroot" ACME
challenges, if that's your favourite) to one or all of the backend
servers. Alternatively, you could use DNS challenges and avoid
the need for this forwarding.
6. One of the backend servers uses ACME (or some other means) to
legitimately acquire a certificate for "submission.example.com".
This has nothing to do with the individual server's internal
hostname. The certificate is for the logical cluster that you
control, and can get a certificate for.
7. Some suitable process arranges to update the peer servers
whenever a new certificate is obtained by some (random or
designated) server in the cluster. Or some completely
separate provisioning system could do the certificate
acquisition and push the cert files, ...
You end up with:
client ---> submission.example.com ---> backend server
(actually IP of haproxy)
with the backend server's certificate containing
"submission.example.com" as one of its DNS Subject Alternative names.
It couldn't be simpler. For some reason you seem fixated on the idea
that certificate names match individual physical hostnames, and that
the primary hostname (rather than a CNAME) of the host that terminates
the TCP connection must be the name in the certificate. These
assumptions are leading up the garden path...
--
Viktor.
