It’s a common problem: You have a bright, shiny new SharePoint installation, and you suddenly realize that before you can put it on the Internet, you need to set up SSL and redirect HTTP for all your Web applications. HTTP works fine for an intranet sometimes, but HTTPS and SSL are essential for Internet deployments for security’s sake.

Once an SSL certificate is installed, you need to find a way to capture any HTTP requests for your SharePoint server and redirect it to the SSL-encrypted site. At first you may assume there is a standard way to redirect HTTP to HTTPS in SharePoint, but after a little time combing the search engines, you’ll find out there isn’t.

There are several ways of dealing with an HTTP-to-HTTPS redirect; ASP scripts and the built-in HTTP redirect in IIS are two popular examples. In the SharePoint world though, where there can be so many different URLs to deal with, it can get to be a little tiring to create a redirect for each one. So how can we create one rewrite that will cover our SharePoint Web applications?

So let me introduce the URL Rewrite extension for IIS.  Install the URL Rewrite by using the Web platform installer option, or by downloading the x64 version and launching it on your SharePoint Web front end(s). URL Rewrite is a Swiss Army knife of IIS optimization, and I am not even going to begin covering all the uses it has.

Before I go any further, however, let me caution you: URL Rewrite is powerful, but dangerous. Whenever possible, thoroughly try any rewrite rules in a test system before putting them in your live environment. Rewriting and redirecting SharePoint URLs can cause unpredictable or even damaging results; use extreme caution.

With that warning in mind, let’s set the stage for our example. Our test farm has multiple Web applications on the Contoso domain (team.contoso.com, portal.contoso.com, etc.) Each Web application is set to use a wild card certificate for *.contoso.com over HTTPS, and none of them any longer have a binding on port 80. For example, team.contoso.com:
_

Now we need a Web application that will capture all those HTTP requests, no matter which specific URL is the final target, team, portal, MySite, etc. This Web application does not need to be a SharePoint Web application; in fact it is better if it isn’t. It just needs to be bound to any requests on port 80, like this:
_

Once all that is in place, we just need to make a simple rule using URL Rewrite.