Our (my) use of
local always means the machine you are currently working on. e.g . local host. I’m afraid after 30 years of using the word that way I won’t be able to change that
The conventional way to distribute a certificate to multiple IIS servers is to use the windows CCS (Centralised Certificate Store). We have a Deployment Task called Deploy To CCS which performs this action (exporting to a local path or UNC share with the required file naming conventions).
You can of course script the deployment using powershell but CCS is is easiest option. To script the deployment you would need to store the certificate in each machines certificate store and add/update your IIS https bindings via the IIS Admin API so that the required IIS and machine level port/IP bindings are maintained. We don’t have a deployment task for this scenario but in the future we plan to have a way to subscribe one instance of Certify to another, so that you can perform the subsequent deployment of a certificate that is managed by a central renewal service.
For deployment to Linux servers you have the option of scripting it yourself (powershell) or using any of the Deploy To Apache/nginx/Generic server tasks (all of which support copying via SSH/SFTP, but not currently SCP-only), or using the ‘Export Certificate’ task which lets you choose individual certificate components to export. You can also use the ‘Run…’ task to execute a remote shell script such as restarting Apache on a Linux host.
Another option for certificate deployment at scale is to store your certificate in a secrets store. We have Tasks for Hashicorp Vault and Azure Key Vault but you can also script it yourself. Then on your hosts simply poll the secrets store regularly for the latest certificate (e.g. monthly) with curl or any other method and apply them with your own script.