How to Configure IIS URL Rewrite for HTTP to HTTPS with Custom Ports (1000 to 1443)


2 views

When working with IIS URL Rewrite, the standard HTTP-to-HTTPS redirection works perfectly for default ports (80 → 443). However, things get tricky when using custom ports like HTTP on 1000 and HTTPS on 1443. The typical rewrite rules don't account for these scenarios.

The common approach using {HTTPS} server variable and {HTTP_HOST} doesn't properly handle port specifications. The {HTTP_HOST} variable includes the port number, which causes issues when redirecting between different ports.

Here's a working configuration that handles the port-specific redirection:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Custom Port HTTP to HTTPS Redirect" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{SERVER_PORT}" pattern="^1000$" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}:1443/{R:1}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

1. Uses {SERVER_PORT} instead of {HTTPS} to specifically match port 1000
2. Explicitly includes the target port (1443) in the redirect URL
3. Uses permanent redirect (301) for better SEO

If you need to handle both the domain and IP address cases, you might want to modify the rule like this:

<rule name="Comprehensive Port Redirect" stopProcessing="true">
  <match url="(.*)" />
  <conditions logicalGrouping="MatchAll">
    <add input="{SERVER_PORT}" pattern="^1000$" />
    <add input="{HTTP_HOST}" pattern="^(.+):1000$" />
  </conditions>
  <action type="Redirect" url="https://{C:1}:1443/{R:1}" redirectType="Permanent" />
</rule>

After implementing these rules, test them with:

  1. http://yourserver:1000 → should redirect to https://yourserver:1443
  2. http://yourserver:1000/path → should redirect to https://yourserver:1443/path
  3. https://yourserver:1443 → should not redirect (already secure)

For high-traffic sites, consider adding these attributes to the rule:

<rule name="Optimized Redirect" enabled="true" patternSyntax="ECMAScript">
  ...
</rule>

When working with non-standard ports in IIS (like HTTP on 1000 and HTTPS on 1443), the standard HTTP-to-HTTPS rewrite rules need special modifications. The default rules assume standard ports (80/443), which won't work for custom port configurations.

Here's the corrected XML configuration for your web.config file that handles port-specific redirection:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect HTTP 1000 to HTTPS 1443" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
            <add input="{SERVER_PORT}" pattern="1000" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}:1443/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

The solution adds two critical conditions:

  • {HTTPS} = off: Ensures we only redirect insecure requests
  • {SERVER_PORT} = 1000: Specifically targets requests hitting port 1000

After implementing this rule:

  1. Make a request to http://yourserver:1000/path
  2. You should be automatically redirected to https://yourserver:1443/path
  3. Verify the redirect preserves all query strings and paths

For environments with multiple HTTP ports that need redirection:

<rule name="Multi-port HTTP to HTTPS redirect" stopProcessing="true">
  <match url="(.*)" />
  <conditions logicalGrouping="MatchAny">
    <add input="{HTTPS}" pattern="off" />
    <add input="{SERVER_PORT}" pattern="1000|1001|1002" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}:1443/{R:1}" />
</rule>

If the redirect isn't working:

  • Verify the URL Rewrite module is installed
  • Check the application pool identity has proper permissions
  • Examine failed request tracing logs for detailed error information
  • Ensure no conflicting rules exist in parent configuration files