Seems like more and more lately, I’m hearing about people that want to use SharePoint in a split DNS environment.  Split DNS just means that users on the internal corporate network (corpnet) resolve a name to a different IP address than users outside corpnet.  For example, you may create a web application that uses a host header called http://employees.foo.local.  When someone on corpnet types that address in the browser, you want to direct them to a set of web front ends on the internal network.  When someone from outside corpnet types that address, you want to direct them to firewall or proxy device in the extranet.

To further complicate matters slightly, you will typically want users outside corpnet to access the site over a secure connection (SSL), but internal users will access the site unencrypted over plain HTTP.  Sounds easy enough, right?  That’s what I thought too, until a recent batch of snow here in the Pacific Northwest left my brain in the deep freeze.  Fortunately Troy Starr helped me stumble through my disconnect and so it is with his assistance that I am sharing this info today.

The first and most important thing to remember, is that we always want to have an IIS virtual server backing each zone we create for Alternate Access Mappings.  So, using our example above of wanting to use split DNS to route corpnet users to http://employees.foo.local and external users to https://employees.foo.local, here’s how we go about things.

The first step we’ll take is to create a new web application.  For the Port we’ll use 80 and Host Header will be employees.foo.local.  After we configure all of the rest of our settings, just confirm that the Load Balanced URL is http://employees.foo.local, then create the web application.

After that has completed, in Central Admin choose the option to Extend an Existing Web Application.  In the Web Application drop down list click on Change Web Application and select the web application you just created.  This time, put 443 in the Port edit field and leave the Host Header edit field blank.  In the Security Configuration section, choose Yes for the Use Secure Sockets Layer (SSL): option.  Then, in the Load Balanced URL edit field type in https://employees.foo.local.

Okay, from a SharePoint configuration standpoint, you are finished.  If you look in the Alternate Access Mappings collection for the new web application, you will see two entries – both for employees.foo.local; one as http: and the other as https:.  The final step is the installation of the SSL certificate.  While I won’t go into the step-by-step details of that here, I will say that you need to make sure you install the certificate in the IIS virtual server that had no value in the host header (i.e. the IIS virtual server that backs the SSL zone).

So, how does this work if you have no host header in the IIS virtual server you are using for SSL?  Well, that’s because in our scenario it’s the only virtual server that is listening on port 443, so everything “just works”.  If you have a scenario where you need to use split DNS with http and https access across multiple web applications, then things get a lot more complicated.  But that is more of a fringe case so that story will have to be told another day.  Hope this helps those of you that need to implement this solution.