For multi-server configurations using the same cert my suggested strategy is:
- Make one server in charge of renewals, it doesn't strictly need to be one of the webservers
- Use DNS validation instead of http challenges, that way you don't need to coordinate the http challenge response on all of the servers.
- Alternatively it's still possible to use http challenges if you write the challenge response to a shared volume and make that accessible at /well-known/acme-challenge on all responding servers.
- Yet another solution is to direct all /.well-known/acme-challenge requests to a single server.
- Consider using a secrets store (hashicorp vault etc) for your cert full chain file and key file, this way your authorized servers can just pull the latest version of the files as regularly as they like. If the files have changed you should then move the new files to your individual servers certificate path then reload your server configuration to pick up the latest certificate. Using a file share for certs is ok but you'd still need something to signal that the configuration should be reloaded.
Ultimately, certificates are just comprised of the public key/certificate and the private key that was used to request the certificate from the CA. These are commonly PEM encoded text files (or alternatively a .p12/pfx archive) that can just be copied around, but each service that needs them must known where to look and must know to reload them when they change.
Acquiring a certificate (using an ACME client) can be completely disconnected from deployment (applying the cert to your services), but the most common usage is to acquire and deploy on the same machine which is use case certbot etc are optimised for.