We have a web app that serves a large number of websites from a single IIS website. The IIS website simply has a catch-all binding on port 80. Up till now, for the SSL bindings, we have added a new IP to the machine for each domain that needs SSL, and added an SSL binding to that specific IP address.
Now we are investigating Centralized Certificate Store. We thought we could now have a catch-all SSL binding that would just use the hostname provided and look up the certificate in CCS. But this seems not to be the case. You can add a catch-all SSL binding with a specific cert installed on the local IIS, or you can add individual SSL bindings using the CCS but you have to specify a hostname.
If I am correct then this is a gotcha for us; we will still a binding for every certificate in use, even if the certificate itself is in the CCS. Am I correct?
EDIT: This is a massively tenanted application. There are about a hundred clients being served, with thousands of unique hostnames, all running on the same web application; the application uses a database to determine what content to show for each hostname.
Having a separate binding for every hostname that is used to access the application is a total non-starter. And keeping the SSL certificates loaded in the local IIS instance is also a non-starter; we've been managing it this way up til now and it is getting unwieldy.
On port 80, I can have a catch-all binding; any hostname used to connect will be directed to the web app.
On port 443, apparently I can't do that unless the certificate is loaded in the IIS instance instead of CCS. And only one wildcard certificate per IP address can be used this way. I can't have it use the SNI-passed hostname to look up the proper certificate; the passed hostname must match a binding first.
The ideal situation would be if I could just have a catch-all binding on port 443 with it automatically looking up the proper certificate based on the passed hostname. It doesn't appear that IIS wants to let me do this.
This is extremely depressing. It looks like we are going to have to give up IIS for this much and offload all SSL to something based on Apache, which seems much more flexible.