Just Another IIS Blog : appcmd

IISRESET light

thomad — Tue, 06 May 2008 22:41:46 GMT

Note: This blog entry used to be on my old blog. I'm about to shut it down so I thought I replicate some of the content here.
Many IIS customers use IISRESET to get IIS back into a vanilla state. IISRESET is a pretty heavy hammer however and not needed most of the time - why would you restart FTP, WAS and W3SVC and all worker processes just because one of your web applications is locking a DLL or some content. Recycling the Application Pool causing the problem is usually enough. If you don't know which Application Pool is making the trouble you can recycle all of them. Here is how you do it with APPCMD:

Recycling the Default Application Pool:

%windir%\system32\inetsrv\appcmd recycle AppPool DefaultAppPool

You can use the APPCMD piping feature to recycle all Application Pools:

%windir%\system32\inetsrv\appcmd list apppools /xml | appcmd recycle apppools /in

Save this command as "%windir%\system32\IISPOOLRESET.BAT" and use it instead of using IISRESET.EXE. It probably takes some time to overcome the muscle memory of typing IISRESET<enter>.

Hosting Übersites: IIS7 Support for International Domain Names (IDN)

thomad — Thu, 06 Mar 2008 06:19:00 GMT

Let's suppose you are German, you developed an extremely cool web-site and now you want to make it available to your German Bier buddies. The only really fetzig site name you could come up with contains one of these nasty German umlauts: übersite.de (not registered at the time I'm writing this blog).

There are several registrars out there who allow you to register domain names that contain Unicode characters. It's called International Domain Names (IDN) and IIS 7.0 and HTTP.SYS support it nicely.

Here is what you do if you want to try it yourself:

1) Configure IE to use IDN server names for Intranet addresses

You need a browser who converts IDNs into punycode. Name resolution systems like DNS don't work with Unicode and hostnames have to be converted to punycode first. Internet Explorer 7 does this automatically for Internet addresses. For our example you need to instruct IE to do the same for Intranet addresses. Go to "Tools" - "Internet Options" - select the "Advanced" tab and scroll down to the "International" section. Check "Send IDN server names for Intranet addresses".

2) Generate the Punycode representation of your site name

We need to convert the IDN site name to Punycode because existing name resolution systems still live in the good old ASCII world. There are a couple of web sites out there which do Unicode-to-Punycode conversions. Here is one of them: http://www.nameisp.com/puny.asp

The resulting punycode string for übersite.de looks like this: xn--bersite-m2a.de

3) Registration of punycode name in name system

To keep name registration simple we register übersite.de in our hosts file only. This will resolve the site name for local requests.

Open %windir%\system32\drivers\etc\hosts

Add a new line at the end and add the following:
127.0.0.1 xn--bersite-m2a.de

Save and close notepad. The punycode representation of übersite.de is now mapped to your local loopback adapter 127.0.0.1

4) Add a new site in IIS

Almost there. The only thing left to do is to add übersite.de to IIS. Here are the commands I run in cmd.exe (make sure you run in an elevated command shell):

md %systemdrive%\übersite
echo This is the Default Document of &#252bersite.de >> %systemdrive%\übersite\default.htm
%windir%\system32\inetsrv\appcmd add site -site.name:übersite -bindings:http://übersite.de:80 -physicalPath:%systemdrive%\übersite

5) Request übersite.de

Now you just have to enter übersite.de into the address bar of Internet Explorer.

And in case you have no idea how to enter "ü" on your keyboard: turn on NumLock and enter <Alt>+0252. International Domain names of course do not just work for German Bier buddies but for all characters that can be represented via Unicode characters.

Credits: thanks to Jeong Hwang Kim who gave me the idea to this blog entry.

SSL certificates on Sites with Host Headers

thomad — Sat, 26 Jan 2008 07:06:00 GMT

Today I got the following question:

"I have two sites (siteV1.mysite.com and sitev2.mysite.com). They listen on the same IP address and port. We generated a certificate for siteV1.mysite.com and SSL is working properly. The problem is that some of our customers use siteV2.mysite.com and they are getting certificate errors. What's the problem?"

Here is the issue:

There are three pieces of data to uniquely identify an IIS site:

The IP address
The Port
The Host name which HTTP 1.1 clients send as an HTTP request header.

This IP:Port:Hostname triplet is called a binding. The binding "192.168.1.192:80:myserver" for example represents a site that listens on IP address 192.168.1.192, port 80, host-header myserver.

The very first things IIS (HTTP.SYS to be more precise) does when a request comes in is to read the site's configuration. Connection limits and timeouts are examples of site configuration. The site binding is used to find the right site configuration. The SSL certificate seems to be another great example of site configuration - the SSL certificate is needed to decrypt the encrypted SSL data coming from the client.

And the IIS User Interface certainly makes it appear as if the SSL certificate would be site configuration, too - doesn't it? In reality however you can't bind a SSL certificate to a site. The IIS UI is fooling you. But why?

It's a chicken and egg problem: The host name is encrypted in the SSL blob that the client sends. Because the host name is part of the binding IIS needs the host name to lookup the right certificate. Without the host name IIS can't lookup the right site because the binding is incomplete. Without the certificate IIS can't decrypt the SSL blob that contains the host name. Game over - we are turning in circles.

What IIS does under the covers is to ignore the host name. IIS binds the certificate to IP:Port and warns you when you try to bind a certificate to the same IP:Port combo with different host names.

But there is a way if you need two different sites on the same IP:Port. You can accomplish this by getting a certificate that contains both common names, i.e. sitev1.mysite.com and sitev2.mysitem.com. Cert Authorities usually allow more than one so called "common names" in a certificate. By binding the certificate to one of the two sites you won't not get certificate errors anymore. The client is happy if one of the names in the certificate matches.

But there is another caveat: you can't use the IIS7 User Interface to add a host header to an SSL site binding. You have to use command-line tools, do it programmatically or edit applicationhost.config directly. Here is an example and a link how you can it via command-line:

appcmd set site /site.name:"MySite V2" /+bindings.[protocol='https',bindingInformation='*:443:sitev2.mysite.com']

And last but not least: with IIS7 you can use the following command to figure out what certificate is bound to a particular IP:Port combination:
netsh http show sslcert

This command will show the IP:Port binding but also some other SSL settings.