Some info on how IIS works with host headers and SSL:
You shouldn’t have two sites setup with the same host header (even if
they are on different servers, UNLESS you are using load-balancing!).
A suggestion might be to call it site.dev.domain.com , site.qa.domain.com,
site.domain.com as you go through devlopment, testing, and production
Also, you have to understand how IIS works. It receives a request for
“domain.com” and looks to see if there is a virtual server listening
on port 80 (because no port was defined in the request) that is
listening for domain.com (using a host header). If it doesn’t find
one, it looks for a site listening on port 80 with no host header
defined. If it can’t find one, then it will return a bad host name
So, you need to make sure you have one, and only one, IIS virtual
server with the host header value of the site, listening on port 80
(you can use a different port, but you will of course need to use
domain.com:new port notation), not assigned to an IP address. If you
have been playing around with the configuration, it might be that the
site is “stopped”. Click on the virtual server and refresh the screen
to see if it truely is running.
Also note, host header values do NOT come into play when dealing with
SSL. You can only have one SSL site running on port 443 per server/IP
address. But since you shouldn’t use IP address assigning, you can
only have one SSL protected SharePoint site per server using port 443
(again, you can use a different port, but your users will have to type
https://domain.com:new port or you can use link translation with
products such as ISA).
So, you can have multiple SSL sites on one web server. You would
configure them on different IIS virtual servers with ports like 443,
4443, 4444, etc. Then, have link translation going; when a request is
received for https://site1.com, the person is directed to the web
server on port 4443, for example.