Self-hosted Web Service on Windows Server 2012

When it comes to hosting web services, Microsoft Windows Server platform can do the job with or without an actual web server. In Windows Server, web server would be IIS. If IIS is installed, web service can be hosted as a website, be configured using .config files, and generally speaking all TCP/IP or SSL configuration would be done at the IIS level. This may be more convenient for people who are used to IIS or who have to have IIS up for other reasons, however in some cases you may prefer to avoid IIS and keep your attack surface to the minimum.

Self-hosting means no IIS to install and it relies on http.sys, something that is present on all Windows Server machines as part of the TCP/IP stack. Self-hosted services can be managed through netsh command line interface.

Discussion of pros and cons of self-hosted web services is outside the scope of this article but a good place to start reading up on that is on Stack Overflow.

Self-Hosted Web Service Installation

Self-hosted web service relies on something else other than IIS to open a socket and listen for inbound connections. This can be done by deploying your application as a Windows service. .NET Framework has a handy utility called InstallUtil.exe, located in C:\Windows\Microsoft.NET\Framework\v4.0.30319\ folder (.NET Framework 4.0, Windows Server 2012).

Now this last command is a little tricky. How do you find out certificate_hash and app_guid of your certificate and application?

Certificate hash can be obtained directly by inspecting X.509 certificate using Certificates MMC snap-in, or via certutil -store command. Find the certificate you want to use, copy its “cert hash” value (deleting all spaces) and you are set.

Getting App ID is a tad more complicated. Best way to do this is by calling it from the code using the following method:

Call this method somewhere in the opening lines of your web services application and either Debug.Print the output to the console, or write it into event log, or simply break-point it and check it out in the immediate window. App ID does not change but getting it isn’t very convenient.

Verify Configuration

That’s all there is to setting up self-hosted web services on the Windows Server 2012 platform. Make sure that your Windows Firewall, if enabled, is configured to allow port 80/443 (as applicable).

At this point, start Windows service that was installed using InstallUtil.exe.

To confirm that your socket was opened successfully:

Netstat -na

To confirm configuraion of URL ACL:

netsh http show urlacl

To confirm SSL certificate binding:

netsh http show sslcert

Closing Thoughts

Ultimately, it is up to you to configure the type of network binding (http or https) and the service URL (https://www.flexecom.com:443) of your web service. There are several ways to do this, the preferred way for self-hosted web services is to set these parameters directly using .NET code within your assembly. Whatever settings you configure, they need to match the netsh configuration (specifically URLACL), otherwise your service will fail to open the socket. SSL certificate is required for HTTPS bindings. More on how to do this in another post.

Binding Multiple Web Services to the Same Socket

Is possible! All you have to do is modify the URL of the web service in your code and make sure that netsh command gets executed to add all web service URLs to the http ACL. You can have many web services running off the same base URL (https://www.flexecom.com:443) as long as what follows after / is unique. This allows you to setup a production web service as well as a dev/qa web service using the same single-name SSL certificate, the same public IP address, and the same server.

Another note… if your app code is searching for the certificate by a subject name, and if the subject name of a newly installed certificate matches a subject name of another certificate in the store (such as in the case of renewing an existing certificate), the code may fail to open a network binding with a new certificate if it finds more than one match based on the same subject name. It really depends on the app code. Obviously, solution is to delete the old certificate.