Will Certify the Web deploy the same wildcard certificate to several hosts with IIS?
The Deployment page looks spotty on the subject of IIS and multiple hosts.
As a side note : I’m also interested in deployment to Linux servers.
BTW I hate the word local in context of computers since it can mean anything from several machines to the host the software is hosted on.
Hi Tarjei,
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.
Note that if all of these IIS servers are running different websites then the better option is to have each server renewing it’s own certificates. If they are load balancing the same sites then CCS is still the best deployment option.
I don’t see CCS as a particular easy option when you have to do the rest of the task of changing a certificate. Copying the certificate from a share into ‘cert:\LocalMachine\WebHosting’ is a single line in a PowerShell script.
Changing the certificate automatically in IIS seems to be a matter of having a sensible subject or friendly name on the certificate in addition to identifying the issuer. This is where the work is.
Tarjei, if an IIS server is already configured to use CCS then only deployment required for certificate updates is the file copy.
Changing the certificate in an existing (non-CCS) IIS binding is based on the certificate Thumbprint (technically it’s a registry change to the assigned IP/port combination and an update to the IIS applicationhost.config but the IIS admin API does this as a transaction) and the PFX friendly name is not used by IIS at all. Subject name and SAN names are also not really used by IIS, you can easily assign the wrong cert to a binding in IIS and it will try to use it.
Note also that IIS https bindings must be marked SNI for IP/port sharing across multiple domains, otherwise you need a different IP for each domain.
As mentioned, the simplest solution is for each server to renew it’s own certificates. The more centralised option is to use CCS. Other custom solutions can be achieved using a combination of deployment tasks and custom scripting.
Thanks!
I will have to read up more on the Centralised Certificate Store.
Most of the internal IIS servers should be able to use it.