How to correctly request multidomain certificates for IIS

[defacto64]

Hello folks,

sorry if I am asking an old question, but I could not find a specific guidance in the online manual and reference.

If I have multiple websites on a Windows Server, all supported by IIS, each responding to a different domain (e.g. site1.domain1.com, site2.domain2.org, etc.), what's the proper way to request a multi-domain SSL certificate covering all those N domains, from the wacs command line, and have it automatically installed into IIS ?

[WouterTinus]

From the top of my head --source iis --siteid s --installation iis

[birbilis]

When you write "s" there, is it some special value that means all? At https://www.win-acme.com/reference/cli it mentions a comma-separated list for multiple sites and from what I've seen those IDs are integers, so I wonder what s means above

--siteid
Identifiers of one or more sites to include. This may be a comma-separated list.

[WouterTinus]

Yes, s is a magic value meaning all current and future sites. It's only documented as an example at https://www.win-acme.com/reference/plugins/source/iis though, so I should probably get around to updating that reference sometime 😄

[birbilis]

the -s parameter for --siteid seems to work ok to make a multidomain certificate

I also used --setuptaskscheduler since I was getting an unrelated warning at first regarding the renewal task's healthiness.

I'd expect
--installationsiteid s
to also work and bind to all sites, but it doesn't (seems to only add the binding to the first site in IIS). I can use a number instead of s there but still it works for the first one (the others seem to ignore as "duplicate binding" which it isn't when you have a multidomain certificate combined with an explicit hostname [or say with other port] in the binding)

this is quite problematic - after some research, I decided I should try to manually edit %windir%\System32\inetsrv\config\applicationHost.config
to fix those extra HTTPS bindings I had added via the IIS UI by hand (since winacme wasn't adding them at all)

...the UI of IIS7 seems to have the host name field disabled when you pick HTTPS. Editing the entries in that IIS web server's configuration file by hand to add hostname in each such HTTPS binding fixes this as long as you don't use the UI again on the HTTPS binding, it doesn't even read the value you added for hostname in that UI, apart from having the field disabled (the HTTP binding UI did allow to enter a hostname, definitely needed when you have a single IP and multiple domains).
...Wonder if the opensource Jexus Manager (for IIS / IIS Express / Jexus WebServer) UI works better there regarding manually adding via a UI the https bindings that winacme fails to add, just spotted it and haven't tried it yet but looks promising.

btw, note that on Windows Server version that had IIS7 there was an extra issue with the networking stack that forces one to use a wildcard certificate (that one is complex to get with winacme since you need to set up acme-dns or similar for security reasons and do entries in parent DNS too), or a multidomain certificate (which proved to be much easier, without touching DNS entries). It forces people to use those since in that networking stack you can't have more than ONE certificate PER IP address, which is quite unfortunate.

Now my only problem is that it works when I'm inside the VPN only and not from the outside world but I guess it's some firewall or other routing issue I have to resolve for that

I assume the automatic renewals will work ok since you had mentioned in other discussion:

The good news is that no matter what, the IIS plugin will always update all bindings using the old certificate to use the new certificate, no matter which site they are on

[webprofusion-chrisc]

Server 2008 (IIS 7) does not support SNI, that's why you can't have more than one cert binding per IP. You are using the application in a deeply unsupported configuration.

You should migrate from Server 2008 as a matter of urgency.

[WouterTinus]

The logic of the IIS binding creation is documented here: https://www.win-acme.com/reference/plugins/installation/iis

The reason why it's so conservative is that messing around with the bindings (especially those without SNI, like in your case) is not without risks of causing significant downtime. We've had users literally reinstall their servers because they were not able to figure out how to recover after IIS/Windows got into a "confused" state (you have to use the netsh command line tool to adjust kernel level bindings in such scenarios).

We've come a long way with debugging, unit testing and optimizing around these edge cases, but the fact of the matter is still that the IIS UI seems to be more stable than the API/SDK that we can call from automation.