SSL and Host Headers: Configuring them + Undocumented, Known, and Safely Ignorable Bug

I’m working with a medium MOSS farm for an extranet. I’ve got two web front ends and a SQL Server. The web front ends host several Web Applications, including Central Admin (on Server A), SSP Admin (on Server B), the Extranet site (on both), and Extranet My Sites (on Both). Ideally, we would run Central Admin and the SSP Admin on a middle tier box instead of a front end box, but budgetary constraints dictate otherwise, so Central Admin and SSP Admin are carefully protected with firewall rules that make them inaccessible from the Internet. Additionally, we are running the SSP Admin, Extranet, and My Sites over SSL. SSP Admin is on port 8181, and does not use a host header. It is only on one web front end. The Extranet site and the My Sites site however have to use port 443 since that is the standard SSL port, and since this is an Extranet we need to stick with those standards as we cannot assume that business partners will be able to use nonstandard ports. Since the two web applications use the same ports and IP addresses, they must have different host headers. The main Extranet site will be on and the My Sites site will be on

To set this up however becomes a bit interesting. I’ll assume that you have a wildcard certificate already. You have already added that certificate to each web application. You just need to set up host headers for the SSL port for each of the two web applications. Except that when you go into IIS, this is what you see. The left pile of dialogs is for working with non SSL sites, the right is for SSL sites.

Notice something missing? THERE IS NO TEXTBOX for entering a Host Header value for an SSL site. So how do you do it? Command Line!

There’s a TechNet Article (, but it’s missing a few helpful details.

The command line that you need in order to set an HTTP Host Header is:

cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings “:443:<host header>

ADSUtil.vbs is in c:\inetpub\adminScripts (or whichever drive InetPub is on.).

Figuring out the site identifier take a few more commands, as follows:

  1. cscript adsutil.vbs enum /p W3SVC will give you a list of all the sites, such as:


    The sites are listed in the same order in both the IIS MMC and in adsutil.vbs.

    Therefore, you can guess that the site identifier for is /W3SVC/1417082536, and you can verify this by running the command:

  2. cscript.exe adsutil.vbs enum /w3svc/1417082536/



This confirms that the site identifier is /W3SVC/1417082536 because the Server Comment matches the description displayed in the IIS MMC.

  1. Now you can run cscript.exe adsutil.vbs get /w3svc/1417082536/SecureBindings to see what the value is before you make the change.
  2. Now you can run cscript.exe adsutil.vbs set /w3svc/1417082536/SecureBindings “:443:<host header>

When you do this, the command will confirm back to you your action.

Once this is done, you will be able to start the site in question. If not, is the non-SLL port in use by another site? You need to specify available ports for both SSL and non-SSL settings, even if you only want the site to work over SSL. There’re a “Require SSL” checkbox in the web application’s properties in the IIS MMC for forcing the site to only use SSL.

At this point, I’ll assume that you have the site(s) up and running in the IIS MMC, and no complaints from the MMC.

Here’s something interesting though – go look in the event log. Do you see this event?

Event Type:       Error

Event Source:     W3SVC

Event Category: None

Event ID:           1113

Date:                11/15/2007

Time:                1:46:10 PM

User:                 N/A

Computer:         moss


One of the IP/Port combinations for site ‘1417082536’ has already be configured to be used by another site.  The other site’s SSL configuration will be used. 


This was obviously worrisome to us. We were concerned that our configuration was bad in some way, and this was for our production environment. We called PSS – Microsoft Premier Support Services, and a Support Engineer for IIS/ASP.NET confirmed the following for us, which we were able to communicate to our client as The Official Word from Microsoft:

The event is raised to indicate that there are duplicate SSL bindings. Prior to Windows 2003 SP1 this was not supported. This functionality was added in Windows 2003 Service Pack 1 and can be ignored.”

In other words, prior to Windows 2003 SP1, this error message was accurate, but after they added support for multiple SSL host headers in SP1, they forgot to remove the message. Oh well, at least the SSL configuration works.


PS, many thanks to my friend Ralph who did most of the work with this issue. It’s a lot of his hard work and a little bit of mine that I am documenting so that this information about using SSL in MOSS can be better known.