2

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.

2

In IIS 10 you can have:

Name              Bindings
----              --------
Default Web Site  https *:443:*.bar.com sslFlags=3
                  https *:443:*.bar.net sslFlags=3
                  https *:443:*.foo.edu sslFlags=3         

and use the CCS for all bindings, but you can't do:

https *:443:*.*.com sslFlags=3  

or

https *:443:*.com sslFlags=3

So if all your domains are different top-level domains this is not very helpful, but if you have something like username.domain.com and the domain is the same for all hostnames it is very helpful.

  • That's interesting .. unfortunately IIS 10 isn't available to us, only IIS 8.5 (Windows 2012 Server R2). – Ross Presser Jul 15 '15 at 10:00
  • 1
    @RossPresser - I didn't expect anybody to use IIS10 yet, I just wanted to mention it because it may be an option for some people in the future. – Peter Hahndorf Jul 15 '15 at 10:03
  • It would at least let us use one binding per wildcard site and allow using all the bindings on all the IPs. That's definitely an improvement over IIS 8.5. – Ross Presser Jul 15 '15 at 14:39
0

You are talking about two different concepts here:

  1. SNI, the ability to use TLS (SSL is dead) based on a hostname, so you don't need a separate IP address for each TLS site.

  2. The central certificate store, which just changes the way IIS is storing the certificates and makes it easier for you to deploy them. To use the CCS you need to define the hostname in the binding because it is used to find the correct certificate PFX file.

But you can mix and match, you can still use certificates stored in the old certificate store for some bindings and the CSS for others.

But you can not have a single binding for everything and tell it to use the CCS.

Tip: Manage your bindings and certificate assignments in a script, never click around in IIS Manager.

  • Apparently I wasn't clear enough. Editing the question. – Ross Presser Jul 14 '15 at 7:15
0

After investigating apache and nginx, I settled on haproxy-1.5. Version 1.5 has integrated https support of exactly the kind I need. After the proper haproxy.cfg has been written to specify the load balancer nodes, all I need to do after that is turn my exported PFX cert files to PEM files using openssl, and dump them in a folder. My catchall binding will work just fine.

Of course I still have the regular problems with reverse proxying ... but nothing different than I had already solved with my ARR balancer.

Here is a portion of my haproxy.cfg (sanitized, of course)

frontend http-in
    bind *:80
    bind *:443 ssl crt /media/windowsshare/myWindowsServer/ssl/pem/
    default_backend myCluster

backend myCluster
    server member1 10.4.0.184:80 maxconn 64
    server member2 10.4.0.185:80 maxconn 64

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.