Redirecting HTTP to HTTPS with URL Rewrite

By Sergey Nosov

August 21, 2014

Hundreds millions of websites hosted on the Internet send pages to their visitors using one of two protocols: http or https. With http, user requests and the pages traverse the Internet unconcealed. Any server between the sender and the receiver is capable of seeing what is going on. Https adds a layer of security by encrypting the information while it transits the Internet.

In an August, 2014 blog post, Google employees Zineb Ait Bahajji and Gary Illyes announced that whether or not a website uses https will now be taken into account by the search ranking algorithms. The announcement signaled to webmasters everywhere that if you want the best possible position for your websites in the Google search engine, you better make sure the websites are served over https and not http.

In this article we will show how to automatically and transparently redirect your website visitors from the unsecured http to the encrypted https version, using the URL Rewrite engine that is available for websites hosted under Windows Server IIS (Internet Information Services).

Before implementing the advice shown here, you should already have configured your secured https website. We show how to do that in our book, "Configuring Windows 2008 R2 Web Server." You should also have the URL Rewrite engine installed, which is a very useful add-on to the IIS; if you do not yet have the URL Rewrite running, you can add it to your server from the Microsoft Web Platform Installer.

If you used the URL Rewrite at all, you probably used it to add a canonical domain name rule to your website for redirecting requests made without “www” to the “www” version of your domain (or the other way around). We will simply modify this rule to also redirect from http to https version of your website.

URL Rewrite rules are normally placed in the web.config file in the root of your web site (though you can have separate web.config files in sub-folders that override settings from the main folder or the folders above).

Following is the web.config file that will do the needed redirects. If you already have a web.confing file with other settings, then merge the new script into the old file by inserting the “rewrite” section before the closing “/system.webServer” tag. Also mind any other rewrite rules you may already have.

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
        <rewrite> 
            <rules> 
                <rule name="CanonicalHostAndHTTPSRedirect" stopProcessing="true"> 
                    <match url="(.*)" /> 
                    <conditions logicalGrouping="MatchAny"> 
                        <add input="{HTTP_HOST}" pattern="^www\.mywebsite\.com$" negate="true" /> 
                        <add input="{HTTPS}" pattern="^off$" /> 
                    </conditions> 
                    <action type="Redirect" url="https://www.mywebsite.com/{R:1}" redirectType="Permanent" /> 
                </rule> 
            </rules> 
        </rewrite> 
    </system.webServer> 
</configuration>

Replace “mywebsite\.com” and “mywebsite.com” with your website actual domain name.

Let us examine what our script adds to the standard canonical name redirect script.

First, note the “https” in the redirect action; this sends all redirects to the https version of the website.

Second, is the new <add input="{HTTPS}" pattern="^off$" /> condition that evaluates to true when the request to the website was made without https.

The final small change is the logicalGrouping="MatchAny" property of the conditions tag, which lets our rule to fire when ether of the two conditions (malformed domain name or non-https request) are met.

This should be it, upload the changed web.config to the server, and redirects should start working immediately; no restart required.

If your website uses an xml sitemap, examine it for hardcoded http protocol designators; in theory sitemap links should point to final destinations and not to redirects.

Among other things to watch out for is the Require SSL IIS setting. You may be tempted to turn it on, but be aware that if you do, then no content will be served over http, not even the redirect. Instead, your visitors trying to browse the website over unencrypted connection will see an error message like this:

403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.

You should also keep in mind that, especially if your website is hosted on older hardware, https can slow things down. And that may have negative impact on search engine rankings as Google does take the website speed into account.

Another hold back is that if you use Server Name Indication (SNI) to host your secured websites, users of some very old web browsers (such as Internet Explorer (IE) running under Windows XP) will not be able to see your website at all.

The number of people using such old equipment is decreasing, so the trade for an overall more secure Internet may be worth it.

We hope you found this article useful. Good luck!