SSL only works with a specific IP address, a specific host header value, and a certificate. All three of those have to match in order for the packets to be considered “secure”.

IIS has to know what IP address  *specifically* to use for the SSL portion.

Without SSL, IIS can just willy-nilly accept packets on whatever old IP address and process it. But with SSL, the IP address comprises a significant portion of the protocol.

An SSL certificate is only good with one domain name/hostname, and one IP address. It’s the way the protocol is designed.

IE, you can’t have somehost.domain.tld and someotherhost.domain.tld both secured with the same SSL certificate. Each must have it’s own IP address and domain name and separate SSL cert.

If you have host headers configured and the certificate matches the host
header, you should not have problems with SSL on "all unassigned" addresses
with W2K3.

If you are using SSL, each URL must have its own unique IP address. You can only share addresses  with host headers if you are using port 80. You can't do this with SSL.

I think that this is the definitive document on the subject:
www.microsoft.com/.../details.aspx
51D-B213-98ED039190BF&displaylang=en

Also, from the Resource Kit:
www.microsoft.com/.../part
3/c12spprk.mspx

In WSS, you *must* use host headers, even with SSL. After R2 for W2K03 comes out, you’ll be able to use IP addresses  for SSL with WSS, but until then, you must use host headers with SSL

It's not just that you won't have problems, it's that it is *required*
to use host headers in all WSS virtual  servers because, at the present,
WSS does not support IP-bound virtual servers.

Until we get the upgrade to WSS, please remember that we *never* assign  an IP address  to a virtual  server. We can have the IP address at All Unassigned and the certificate will work without the intervening popup box that indicates the cert doesn’t match the address.

Please read my blog on this: mindsharpblogs.com/.../283.aspx