That has been a question we have come across frequently. Before IIS 8, you could host multiple sites needing SSL on a single IP address if the sites utilized the same SSL certificate or used a wildcard SSL certificate.  A wildcard certificate was only beneficial if you needed SSL on the subdomain level of a current site/domain. But what if you had sites with different names? Well, you could get a Subject Alternative Names (SAN) SSL certificate.  This SSL certificate would allow you to protect multiple sites with a single SSL certificate. The last available option prior to IIS 8 required setting each additional SSL site on the same IP address but with a different SSL port number. This would allow you to utilize each site’s/domain’s SSL on the same IP address as another site.  By default, SSL certificates utilize port 443 for secure communication. This port doesn’t need to be specified in the URL since this is the standard port. When you use a different port number for SSL you will be required to add the non-standard SSL port number in the URL in order for it to work.  As you can imagine, this is not the way you want to run a public site. How would a user know to enter the port number and it’s not a common step that users are familiar with doing when browsing a site.

Adding an additional IP address to host another site needing SSL is the common method used but sometimes this isn’t an option for some people. With the inception of IIS 8 on Windows Server 2012, a new feature called Server Name Identification (SNI) was added. This feature offers an easier solution to hosting multiple sites that have a different or individual SSL on a single IP address. This feature is included in IIS 8 by default and doesn’t require the installation of any additional features to begin using it. Below, we will walk through the steps involved with configuring SNI. One thing to note with implementing SNI for your SSL solution, it will not work for those users running Internet Explorer on Windows XP. If your server has multiple IP addresses, you can implement SNI for some sites in addition to assigning individual sites to a single IP address for SSL. Both methods will work along side each other on different IP addresses without issue.

Steps:

1)  One of the first things you will need to do is import the SSL certificates for each site on the server if this hasn’t been done already
2)  Next, open IIS 8 Manager and add your first site that will need SSL
  a.  If the first site is already in place, proceed to step the next step
3)  After the site is added select the site and click Bindings… under the Actions menu pane on the right

4)  Click Add
  a.  Select https for the Type
  b.  You can leave the IP address to “All Unassigned” or choose the IP address you want to use
(If you have multiple IP’s on the server you will want to specify the one you want to use for SNI)
  c.  Enter your site/domain name for Host name
  d.  Check the box for “Require Server Name Indication”
  e.  Select the SSL certificate for the site from the drop down box
  f.  Click OK

5)  Create the second site and add the SSL binding following the steps below
6)  Select Bindings and click Add
  a.  Select https for the Type
  b.  You can leave the IP address to “All Unassigned” or choose the IP address you want to use
   (If you have multiple IP’s on the server you will want to specify the one you want to use for SNI)
  c.  Enter your site/domain name for Host name
  d.  Check the box for “Require Server Name Indication”
  e.  Select the SSL certificate for the site from the drop down box

7)  Click OK to complete the setup

That’s all that needs to be done.  Test SSL for the site to make sure each site is working properly.  If you have additional sites that need SSL added, you can continue following the steps above for adding the SSL binding for each new site.

It sounds like it should be trivial: Create a WCF web library and host it in IIS. Surely lots of people need to do this, and it will be easy in a fairly modern version of Visual Studio like 2012? Previously I have created this article about how to host WCF Service in IIS 8, however I will explain more details in this article.

Whatever the reason, I hope this page will offer a useful step-by-step guide to set up a WCF Service Library project to be run from its development folder on Windows 8.0 or Windows 2012, IIS 8.0 – and I have been using VS 2012 and .Net Framework 4.5 as the target.  Also, before I begin, and something of a spoiler alert; you may prefer to publish your website to a specific location, and host it in IIS from there, rather than try and host it from your development folder.  This option is covered after the walk-through below.

Please Make Sure that You Have Integrated your ASP.NET with IIS

The easiest way to check this is to create a minimalistic web application (e.g. ASP.NET MVC with “No Authentication”) and try to host it in IIS (see configuration steps below). If something is missing, make sure that:

• “Internet Information Services” and “Word Wide Web Services” are enabled in the “Turn Windows Features on or off” dialog.
• If IIS is up and running, but the ASP.NET integration is missing (you can check the ISAPI filters in IIS Manager), you should run “%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –i” and hope for the best (maybe restart the machine afterwards).

Take a look at WCF Service

I assume that you have created WCF service called “WCF Service Application”. Hosting this application in IIS means that you create a virtual directory in IIS, where you link the root folder of your project to a URL. You also need to specify an app pool to be used, which should match to the .NET framework you target (e.g. “.NET v4.5”).

If you have configured your.svc files within the specified URL, you should see a page with some positive messages and links to the WSDL contracts. If you see this, then stop reading, you are done.

However, you can receive an error page, “HTTP Error 404.17 – Not Found”, “The requested content appears to be script and will not be served by the static file handler.”. This most probably means that your IIS is not configured to host WCF services (this seems to be the default).

With .NET 3.5, you had to run the “ServiceModelReg.exe” tool, but this doesn’t seem to be necessary anymore for .NET 4.0+ (“aspnet_regiis” does this already). If you look into the details of the IIS settings, you can see some references to WCF.

The only thing you have to do is to enable “HTTP Activation” in the “Turn Windows Features on or off” dialog under the “WCF Services” node. With this, you basically enable the creation of WCF service instances to serve requests coming through HTTP.

Then, please test it again and you wont see any error message anymore.

I hope this article will help you a lot.