Musing, it might be one cert per socket rather than per IP. Unfortunately, that’s a next-to-meaningless distinction because everyone’s interested in the one port 443 (i.e. nobody wants their website to be the one you have to type a port number for (eg, https://example.com:8443) and it might need reconfiguration at the client-side firewall/proxy too to allow SSL tunneling on a nonstandard port…) and there’s only one tcp/443 per IP.
So, let’s assume one IP per certificate is a requirement based on ISA and Windows’ current implementation. The problem then becomes that all those IPs need to be externally visible at some point (assuming that we’re not dealing with SSL Host Headers).
If you’re running, say, something.example.com, somethingelse.example.com, somethingagain.example.com and so on, these can potentially share a wildcard certificate and use only a single server IP for all those sites.
If your namespace is largely-hierarchial-but-also-quite-flat you may be able to significantly reduce the number of ips and certs required (think site183729.hosting.example.com - all those sitennnns could share one cert…), and it reduces both the number of IPs and certs to manage. It can be done today, so it’s probably worth investigating.
See also the ISA blog here:
Bottom line: In the future, hopefully an SSL equivalent to Host Headers is implemented. Right now, not by us, afaik.
ISA will terminate SSL connections itself (if you let it, which we’d usually suggest), inspect the traffic, then forward the request to the published server internally. So internally, you can use CrazyPKI (if that’s a real product name, I apologize to the vendor, but what were you thinking!? (and I claim first-use rights if not)) or self-signed certs, or no certs, and private IP addresses, so you’re golden there. The “cost” of SSL is in terms of public IPs. Internally, you can use different certs per published site or not (or no certs at all and everything on the one IP using host headers), without preventing you from using wildcard certs externally.
It’s really a question of where you want to manage your cert complexity - you can do it “out front” at the ISA Server/SSL Termination tier and organize sites however you want internally, or you can straight-through the SSL and manage the complexity at the web server.
Sorry for the rather long-winded “it’s up to you”…!