URL Rewrite is the most documented method for forcing HTTPS on IIS, but it’s not always available. Some hosting environments don’t include the module. Others restrict its installation for security reasons.

The good news: IIS offers built-in alternatives that don’t require any third-party modules. We’ll walk through three methods that work on Windows VPS and dedicated server environments without touching URL Rewrite. Each has distinct trade-offs you should understand before implementing.

Use IIS HTTP Redirect for Simple Site-Wide Forwarding

IIS Manager includes a native HTTP Redirect feature that predates URL Rewrite. It’s basic, but it covers the most common scenario: sending all HTTP traffic to the HTTPS version of the same site.

Configuring the Built-In Redirect Rule

First, ensure your site has both HTTP and HTTPS bindings configured. You’ll need a valid SSL certificate on the HTTPS binding before this works.

In IIS Manager, select your site and open HTTP Redirect. Check “Redirect requests to this destination” and enter your HTTPS URL with a trailing variable: https://yourdomain.com$S$Q. The $S preserves the path and $Q preserves the query string.

Set the status code to “Permanent (301)” unless you’re testing. Check “Only redirect requests to content in this directory (not subdirectories)” if you want finer control over specific paths.

Where This Method Falls Short

HTTP Redirect is crude. It doesn’t distinguish between static assets and sensitive pages, which means you can’t whitelist specific paths that should remain HTTP-only.

More critically, it modifies response headers globally. If you’re running multiple applications under a single site or using URL parameters heavily, you might see unexpected behaviour. We’ve seen cases where API endpoints that explicitly require HTTP for legacy client compatibility broke after applying site-wide redirects.

This approach works fine for simple WordPress sites or marketing pages. But it’s not suitable for complex application environments with mixed protocol requirements.

Write a Custom HTTP Module in Web.Config

If you need conditional logic that HTTP Redirect can’t provide, write a custom redirect directly into your web.config file. This method gives you programmatic control without requiring URL Rewrite.

Adding the Redirect Logic

Create a new system.webServer section in your web.config if one doesn’t exist. Inside it, add a rewrite section with a custom rule that checks the incoming protocol.

Here’s the structure: define an inbound rule with a match pattern that captures everything (.*). Add a condition that checks whether HTTPS is off using the {HTTPS} server variable. Set the action type to redirect with the target URL as https://{HTTP_HOST}/{R:1}.

This approach respects query strings and relative paths automatically. And you can stack multiple conditions to exclude specific folders or file types from the redirect.

Handling Edge Cases Without Breaking Functionality

The web.config method shines when you need exceptions. Add negative conditions to exclude paths like /api/legacy/ or file extensions like .ashx that must remain on HTTP.

One gotcha: inherited web.config files in subdirectories can override or conflict with your parent configuration. If you’re managing a multi-tenant environment or application with nested virtual directories, test thoroughly. We’ve debugged situations where a child application’s web.config silently disabled the parent’s HTTPS enforcement.

Also consider load balancer scenarios. If you’re terminating SSL at the load balancer level, the {HTTPS} variable might always show “off” at the IIS layer. You’ll need to check the X-Forwarded-Proto header instead, which requires adjusting your condition pattern.

Combine HSTS Headers with Default Document Redirect

HTTP Strict Transport Security tells browsers to automatically upgrade HTTP requests to HTTPS. It’s not a server-side redirect, but it achieves the same end result for repeat visitors while reducing server load.

Enabling HSTS Through IIS Configuration

HSTS requires adding a custom HTTP response header. In IIS Manager, select your site and open HTTP Response Headers. Add a new header named Strict-Transport-Security with the value max-age=31536000; includeSubDomains.

The max-age parameter sets the enforcement period in seconds. One year is standard for production. The includeSubDomains directive applies the policy to all subdomains, which matters if you’re hosting multiple services under the same parent domain.

But here’s the catch: HSTS only works after the first HTTPS visit. A user typing your domain into a browser for the first time will still hit HTTP initially. You need a fallback redirect for that initial request.

Layering HSTS with First-Visit Protection

Use IIS HTTP Redirect or a web.config rule to handle first visits. Then let HSTS take over for subsequent requests. This hybrid approach gives you both immediate protection and long-term browser-level enforcement.

One consideration: HSTS is difficult to undo. If you set a long max-age and later need to support HTTP for any reason, browsers will refuse the connection until the policy expires. Start with a shorter max-age during testing, like 300 seconds, then increase it once you’re confident.

We’ve seen this bite customers who needed to temporarily disable HTTPS during certificate renewal issues. The browser cache held the HSTS policy, blocking all access until they either waited out the max-age or manually cleared browser data. Not ideal during an outage.

Pick the Method That Matches Your Environment

HTTP Redirect works for straightforward sites without complex routing. Web.config rules give you conditional control when you need exceptions. HSTS reduces server load for returning visitors but requires a fallback for first-time requests.

Start with the simplest method that covers your use case. If you’re running production workloads on a Windows VPS or dedicated server, test your chosen approach in a staging environment first. HTTPS enforcement is critical for security, but implementing it wrong breaks sites.