Follow us:
Clients
The redirect from HTTP to HTTPS in IIS requires URL Rewrite module configuration and proper SSL binding setup. Most administrators who’ve worked with Windows VPS environments know the basics, but the actual implementation reveals edge cases that break silently if you rush it.
This guide walks through the practical steps we use when configuring HTTPS redirects on production IIS instances. We’ll cover certificate binding, URL Rewrite rules that preserve query strings and paths, and the exceptions you’ll need for health checks or legacy applications.
Installing Your Certificate and Configuring HTTPS Bindings
Before any redirect happens, IIS needs a valid certificate bound to port 443. You can’t redirect traffic to HTTPS if the server doesn’t answer on that protocol.
Certificate Installation Process
Import your certificate through IIS Manager or the certificate MMC snap-in. If you’re using a PFX file, the import wizard handles both the certificate and private key in one step. Make sure the certificate lands in the Local Machine store, not Current User.
We’ve seen administrators import to the wrong store and spend twenty minutes troubleshooting why IIS can’t see the certificate. Check Computer Account > Personal > Certificates if it’s not appearing in the binding dropdown.
Binding HTTPS to Your Site
Open your site in IIS Manager and add a new binding. Select HTTPS, choose port 443, and pick your certificate from the SSL certificate dropdown. If you’re hosting multiple sites on the same IP, enable SNI (Server Name Indication) and specify the hostname.
SNI lets you run multiple HTTPS sites on a single IP address. Without it, only one certificate works per IP, which becomes a problem fast on shared hosting environments.
Keep your existing HTTP binding on port 80 active. The redirect rule intercepts that traffic and sends it to HTTPS. Removing the HTTP binding breaks the redirect entirely.
Creating the URL Rewrite Rule for HTTP to HTTPS Redirect
IIS doesn’t include URL Rewrite by default. Download it from Microsoft’s site and install it before proceeding. The module adds a URL Rewrite icon to IIS Manager at both server and site levels.
Building the Rewrite Rule
Open URL Rewrite at the site level where you want the redirect. Click “Add Rule” and choose “Blank rule” under Inbound rules. Name it something obvious like “HTTP to HTTPS Redirect.”
Set the pattern to (.*) which matches everything. This captures the entire path and query string for preservation. Leave “Using” set to Regular Expressions.
Under Conditions, add a condition with input {HTTPS} and pattern ^OFF$. This checks if the request arrived over HTTP. The redirect only fires when this condition matches, preventing redirect loops.
Configuring the Redirect Action
Set Action type to Redirect. The redirect URL should be https://{HTTP_HOST}/{R:1}. This rebuilds the URL using the original hostname and captured path.
The {HTTP_HOST} variable preserves the exact domain the user requested. The {R:1} backreference inserts everything captured by the (.*) pattern, including subdirectories and query strings.
Set Redirect type to Permanent (301). Search engines treat 301s as permanent moves and update their indexes accordingly. Use 302 (Temporary) only during testing phases.
Check “Append query string.” This ensures parameters like ?id=123 carry over to the HTTPS request. Without this checkbox, query strings disappear.
The Resulting web.config Entry
IIS writes your rule to the site’s web.config file. The XML looks like this:
<rule name=”HTTP to HTTPS Redirect” stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTPS}” pattern=”^OFF$” />
</conditions>
<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” appendQueryString=”true” />
</rule>
You can edit this XML directly if you’re comfortable with the syntax. Some administrators prefer templating web.config across multiple sites rather than clicking through IIS Manager repeatedly.
Handling Exceptions and Special Cases
Not every request should redirect to HTTPS. Health checks, certain APIs, and legacy applications sometimes need HTTP access.
Excluding Specific Paths from Redirect
Add another condition to your rewrite rule to exclude paths. Use input {REQUEST_URI} with a negative pattern like ^/health-check and check “Does Not Match the Pattern.”
Multiple exclusions require multiple conditions with “Match All” logic selected. If you need “Match Any” behavior, create separate rules instead of stacking conditions.
We’ve configured environments where monitoring systems couldn’t handle HTTPS certificate validation. Excluding those probe endpoints from the redirect kept alerts from firing constantly.
Application Pool Considerations
The URL Rewrite module processes requests before they reach your application. This means redirects happen regardless of whether your app code expects them. But some .NET applications check request.IsSecureConnection and behave differently.
If your application sits behind a load balancer that terminates SSL, you’ll need X-Forwarded-Proto header logic instead. The {HTTPS} condition won’t work because IIS only sees HTTP traffic from the load balancer.
Add a condition checking {HTTP_X_FORWARDED_PROTO} against ^http$ in those architectures. The redirect still works, but it reads the forwarded protocol header instead of the direct connection type.
Testing Proves the Rule Works Correctly
Open a browser and request your site using http:// explicitly. Watch the address bar. It should change to https:// immediately.
Check that paths and parameters survive. Try http://yoursite.com/some/deep/path?test=value and confirm it lands at the HTTPS equivalent with everything intact.
Use browser developer tools to verify the response code. You want 301 Moved Permanently, not 302 Found. Search engines treat these differently for SEO purposes.
Test from outside your network if possible. Internal DNS or hosts file entries sometimes mask redirect problems that external users encounter. We’ve caught several misconfigurations this way that looked fine from inside the office.