On Wed, May 19, 2021 at 06:20:07PM -0400, post...@ptld.com wrote:
> > 2. This (same) certificate chain and associated private key is
> > deployed on all the backend servers that sit behind the
> > load-balancer.
>
> 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?
Why would the cert be created "on the load balancer"? The load balancer
is just a TCP L4 proxy. Why does it need to be a trusted component in
the system?
> 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.
Certificate renewal should happen on (one or all) the backend servers.
If more than one, space out the cron job times far apart, so that
no two are doing it at the same time. When any one succeeds in
obtaining a new cert, promptly rsync it to the others.
> 2) I could setup NFS mounted drives from all of the backend servers to
> the cert location on the load balancer.
NFS makes the cluster fragile, the whole point is to avoid a single
point of failure. Don't do NFS. NFS is also not particularly secure.
> 3) Is there a better strategy for accomplishing this? What is standard
> procedure for solving this?
Rsync. FOr example certbot never overwrites cert/key files, it creates
new ones, bumping the serial number in the "archive" directory, and then
updates some symlinks. Thus it is quite safe to rsync
/etc/letsencrypt/archive/<name>
and
/etc/letsencrypt/live/<name>
in both directions between multiple servers. Whoever renews first
wins the race.
> 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.
No, it does not have to match any of the names of the actual server. It
just has to match some name you can prove you control. EIther by
forwarding the HTTP and HTTPS ports also, or via DNS challenges, ...
> 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.
No, it does not. It suffices for HTTP traffic to reach that server
via the IP listed in DNS (possibly via CNAME indirection, and forwarding
via a proxy). Or of the server to be able to initiate DNS zone updates,
or ... whatever other "challenges" ACME happens to support.
> 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.
You're fixated on the backend server name matching the certificate,
you really need to drop that assumption.
--
VIktor.
