I remember being quite impressed when first I understood how IIS handles host-names in such a way that a single server can have multiple websites, all on port 80, differentiated only by hostname. I’m sure other webservers such as Apache can do it as well but this was the first time that it actually hit me how ingenious that idea was.
The only absolute in tcp/ip originally was ip address. It was unique at its particular level which means, on the Internet, unique world wide. Like a world wide postal address I can be guarenteed that there isn’t another person out there with the external ip 202.139.111.225.
Hostnames are likewise unique. No-one else out there has the hostname http://www.transend.com.au. I know this, because its registered to Transend Pty Ltd. In fact, no-one out there has any address in the something.transend.com.au range.
Hostnames are great for people, because they are words and words are easy to remember. Thats the original purpose behind them, to translate those numbers, which are great for computers, into something we can remember. It is possible to remember ip addresses, one network technician I knew could recite the ip address of every server he handled (and it was well over 50), but in general its easier for us to remember hostnames.
An obvious step from this is to be able to have multiple hostnames per ip address. The simply all lead to the same place. Not quite as obvious, to me at least, was to be able to differentiate between websites depending on which hostname was used. This is the equivilant of having two houses on the same physical location (impossible I know but bear with me) and the one you see is determined by the directions you followed to get there.
Even more accurately, it doesn’t even matter -how- you got there, the house you arrive at is different depending on the address you were given, even if the different addresses point to the same plot of land.
Technically this is accomplished by examining the headers of a request, comparing the hostname requested to a list of websites on the server and using that to determine which site they want to access.
Simple yeah? Well my question is this. Why can’t they do that for SSL?? SSL port is port 443 and, despite host headers, the server restricts you to only one port 443 site. It’s easy to say “change the port” but thats not simple in a corporate environment, full of hardware and software firewalls and access control lists.
Frankly, its a pain, and doesn’t seem to be a necessary one. Why this illogical choice Microsoft? You’ve shown you -can- give us the option, so you must have chosen not too. Why damn you why!!!!
Ahem.
The answer is probably because you can’t read an encrypted header. If each website has its own security key, then only a particular website can unlock messages intended for it… except that we dont know who they’re intended for until they’re unlocked.
Ah, tricky. What a pain in the proverbial.
This is also a primary cause of the “The process cannot access the file because it is being used by another process.” error, in which IIS refuses to start a disabled website. Generally it means either you havn’t set up host headers, and you’ve got two sites fighting over port 80, or you’ve tried to have multiple sites with SSL certificates and they’re both trying to use port 443.
The solution? Either change the ssl port so that they don’t conflict, only have one of them use SSL or create a supersite that contains the other two sites as application virtual directories. That way they can share a single certificate – though you lose the cool host-header that way.
Personally, i’ve set it up the latter way. I keep the host-header by having a non-secure website with that host header that simply redirects (via asp “Response.Redirect “http://woot.com” ) to the virtual directory. Seems a bit inelegant perhaps, but its working and it has gotten around the firewall port problem.
Oh, and wish me luck tonight. I’ve got an outage. It’s the 6/6/06 and the outage is at 6pm. Outage of the Beast!
Superstitious server admin’s standing by.