On 05-19-2021 5:58 pm, Viktor Dukhovni wrote:
You're not paying careful attention, so I'll have spell it out in gory
detail.
No, follow all of that. I understand that and i *thought* i expressed as
much in my opening email.
2. This (same) certificate chain and associated private key is
deployed
on all the backend servers that sit behind the load-balancer.
This, this part right here. This is what i have been talking about the
whole time.
I was asking what is the best strategy for doing this?
1) Should i just physically copy (scp?) the cert files created on the
load balancer to all the backend servers and tell submission to use the
cert which came from the load balancer? Downside, the backend servers
will not auto renew certificates. Plus in one of your emails you said no
do not copy the certificates to another server.
2) I could setup NFS mounted drives from all of the backend servers to
the cert location on the load balancer. Then tell submission to use the
certs reachable over NFS. This would allow auto renew to work, but im
not sure about security and permission issues (if any) from allowing NFS
to access a cert private key.
3) Is there a better strategy for accomplishing this? What is standard
procedure for solving this?
For some reason you seem fixated on the idea that certificate names
match individual physical hostnames
No, not that it has to match the hostnames. It just has to match some
FQDN and since its a backend server the public doesn't connect to the
only FQDN setup is the hostname. I can add another A record and set the
certificate to that. But whatever i do the certificate HAS to be issued
to a FQDN that resolves to THAT server. Hostname or CNAME or made up A
record, doesn't matter. The point ive been trying to convey is no matter
what it is, it WONT be the same FQDN clients are using to connect to the
loadbalancer, and the clients are expecting a certificate assigned to a
FQDN that resolves to the load balancer they connected to, not the
backend submission server.
