Server Name Indication Support in Mobile Devices

If you’ve ever played around with setting up multiple web sites on your servers using SSL for enabling HTTPS there’s probably a thing that’s been annoying you once or twice – the fact that you can only use one SSL certificate per IP address. (I am assuming IIS is your web server of choice for the sake of this discussion.)

You can easily have,, etc. all tied to the same IP, but once you want to have and things change.

Now of course if you happen to have an ISP which will happily supply you with IP addresses this isn’t a problem (at least in the short term); I have TMG servers with 20 external IPs for this very purpose. But IPv4 addresses are getting harder to come by, and if you try to sign up for 100 public IPs from your DSL-connection at home your ISP will most likely just laugh at you and say “no go”.

But why does it work for HTTP and not HTTPS? Well, the thing is that the host name is included in the HTTP header, and as such the client’s intended host name can be parsed by the web server. With HTTPS an SSL handshake is performed before exchanging headers, and the web server thus cannot base itself on the header information.

Server Name Indication (SNI) is an attempted solution to fix this issue. The domain name is extended to be part of the SSL handshake process, and then you can do for HTTPS what you can do for HTTP.

Fore more background Wikipedia has a decent entry:

And also has an article:
As well as a rudimentary log parser to see how much of your current traffic is from SNI-capable clients:

If you’re in the Linux/Apache camp you’ve probably had support for this for a long time already, but in IIS land things have been less flexible so far. With Windows 2012 and IIS 8 however we can finally do tricks like this with a Microsoft solution as well. If you’ll follow me through a couple of screenshots you’ll see me take the feature for a spin, and we’ll observe how it plays out with mobile devices. (Yes, I know the Wikipedia entry already lists a number of mobile browsers, but it doesn’t hurt to test things oneself.)

The first thing you need to do is install IIS on the server. SNI support is baked into IIS by default so you don’t have to install any extra modules or download anything. I just ran through the steps mechanically without changing anything, but for your viewing pleasure it looks like this:









IIS sets up a default web site for you, which I will use for that very purpose. In addition I need an extra site for the SNI-enabled landing page. Just make a copy of the default site:

I edited the “iistart.html”-file just to include a text that will let us know it’s actually a different page and site Smile

Just insert something right before the closing of the body tag:


You’ll also need to edit your hosts file (if testing on the server) so you have two host names / FQDNs:

Notice that they are both pointing to, but with different names.

You’ll then need to configure IIS. For the “Default Web Site” I’m using a self-signed certificate:

For the SNI-enabled site I’m using a different certificate:

Notice that for this site I check “Require Server Name Indication”, and I also assign a specific host name. This is similar to how you host multiple non-SSL sites (plain HTTP) on the same IP address.

I then go to the command line just to verify the settings by running the following command:
“netsh http show sslcert”


Looks good so far Smile

So, then it’s time to open the browser and check the results; first I open the default site which is not SNI-enabled:

Works like it should – no worries there.
Ok, how about we browse to the other site by changing the address:

Still looks good, but as you can see there’s now a text in the bottom of the page which says “Server Name Indication”. This means that we have been allowed through just like we wanted. You’ll also notice there’s no warning regarding the SSL certificates either as the two different certs match up with the address I browse to.

I tested this with an operating system and browser that supports SNI which is part of the reason why it works Smile

How does it play out if you have a non-supporting OS/Browser combo? To test this I loaded up Internet Explorer 8 on Windows Server 2003. Doing that yielded a certificate error:

You can see that it presents the SNI-version of the site, but it is not able to present the right certificate instead handing out the self signed cert I assigned to the default web site. While broken it does work though.

If however I change the IIS settings to “Require Server Name Indication” on both sites I’ll get this result:

Since the client is not able to handle SNI it simply concludes that there’s no working site at the given address. For a scenario where we test for SNI support this is fine, but probably not what you’d want to do for a site which is supposed to work across as many clients as possible Smile

Let’s run a quick test:
iOS 6 (Beta 4).
Android 4.0 (Ice Cream Sandwich) – both Chrome and the default browser.
Android 3.2 (Honeycomb).
Windows Phone 7.5.

All of the above passes the test. The only of my easily available test devices which didn’t work out was Android 2.2 (Froyo). I haven’t tested things like Windows Mobile, Symbian, etc. so maybe that would change the score slightly, but I don’t get much requests for those devices anyways.

This means that unless you plan to support older Android devices you can easily turn on SNI and use this to serve up different certs and sites from a single IP to your mobile devices.

If you want to test your own device I have my test server running in the cloud. It’s based on the RC build of Windows Server 2012, and I’ll keep it alive for a little while just in case.

I realize that this turned out to contain far less mobile “stuff” than I initially thought starting out. I kind of expected to run into trouble of some sort.  So it ended up as more of a server “stuff” post. Oh, well, that’s just how it pans out sometimes I guess Smile

Leave a Reply

Your email address will not be published. Required fields are marked *