On Wed, May 19, 2021 at 05:13:32PM -0400, post...@ptld.com 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.