I have a windows server with letsencrypt v2 running to manage certs. I am planning to have another server with sites and have a load balancer. I would like know if there is a tool or process that can help me and not put me through to same problems as others in past. So this is more of a help to understand if I should consider somethings in my approach.
There will be two windows servers with IIS and serving websites
There will be a load balancer which is also windows machine.
Now with above assumptions
Is there any migration tool that allows moving certs from one machine to another.
I am not sure if I should move SSL to load balancer or use an SSL store like Azure or AWS and obatain them from lets encrypt at each machine on renewal but update them in central store.
Is there any migration tool that allows moving certs from one machine to another.
If you were on Linux, this is typically handled through scripting a few ways. Usually one machine will get the Certificates and will then distribute them to the other machines. Sometimes the other machines are configured to poll the provisioning machine.
On windows, things are a bit different. @webprofusion maintains the excellent windows client Certify [certifytheweb.com] that I believe has these capabilities. I am not aware of any other windows clients that can do this.
Ideally, you should only get one certificate for each domain or permutation of domains (avoid anti-patterns, adhere to rate-limits, keep yourself safe in case of mistakes), and only have one machine getting the certificates (ease in management).
There are some servers and load balancers that can pull/update certificates from a centralized datastore - cloud or lan - so you only obtain one certificate for use across n machines. Caddy is one server that offers this. There are plugins for nginx/openresty. I believe there are haproxy and apache plugins as well.
The strategy I usually recommend for multiple load balanced IIS servers is to use the windows Centralized Certificate Store (CCS) feature coupled with DNS validation instead of HTTP validation.
CCS is simply a file share (UNC path) that all your servers can see, or a share on each machine that the certificate is copied to, and the PFX files follow a naming convention for each domain. You would then put one server in charge of certificate renewals (it doesn't have to be one of the load balanced IIS servers, but it can be). Clients like Certify The Web have methods to automatically export to the CCS share(s): Deployment Tasks | Certify The Web Docs and you would then update all of your IIS https bindings to pick up from from your share instead of from the machine certificate store.
I recommend DNS validation in this scenario because directing HTTP challenges to the right server can be more difficult, but HTTP validation it's still possible if your load balancer can direct all /.well-known/acme-challenge/ HTTP requests to a single machine, or if you can put redirection in place just for those requests.
Certify The Web doesn't yet have cooperative http challenge responses (where any machine could dynamically answer) and I'm not aware of any currently maintained Windows clients that do, but we may add it in the future in some form.
If you opt not to use the CCS feature you could still just install the client on all machines and have them manage their own certificates (storing in the machine certificate store and updating the IIS https bindings) but this has more opportunity for the shared configuration to drift and become inconsistent.
Another strategy (as you suggested) is to use a front end reverse proxy which serves all the end user traffic, load balanced back to your servers, usually with some kind of session affinity. This can be cloud based and the certificates would be maintained on that service. You can either use the services own certificate management or you can publish certificates into it (e.g. Certify The Web has a Deploy to Azure Key Vault task, amongst others).