Having two websites on the same IIS server accessible with SSL certificates and URL Rewrite Enabled

Question

Having two websites on the same IIS server accessible with SSL certificates and URL Rewrite Enabled

Kaplan, Andrew H 226

Hello.

I am running two websites on the same IIS server. Both sites go by the same URL, but the second one is accessible via port 10000. The respective URLs are the following:

<recovery.domain.com>

recovery.domain.com:10000

Recently I requested and received an SSL certificate for the parent server. The certificate has been bind(ed) to the first site. Additionally, the URL Rewrite module has been installed, and a rule that automatically redirects traffic from port 80 to port 443 has been set up for use. This rule is working for the first site.

The problem is the second site, which uses port 10000, is now inaccessible. Is it simply a matter of creating an additional URL Rewrite rule, or are there other steps that need to be done?

0 comments

2 answers

Your answer

Answer 1

Tom Tran (WICLOUD CORPORATION) 5,785 Microsoft External Staff Moderator

Hi @Kaplan, Andrew H ,

Thanks for sharing the details.

I would first check the IIS bindings for the second site. This does not sound like something URL Rewrite alone would fix.

If the second site is expected to work over HTTPS as:

https://recovery.domain.com

then that site needs its own HTTPS binding on port 10000 with the certificate assigned to that binding. The certificate bound to the first site on port 443 does not automatically apply to the second site on port 10000. Microsoft’s SSL setup guidance lists creating an HTTPS binding as part of configuring SSL for a site.

The URL Rewrite rule may still be involved, especially if it redirects requests to the default HTTPS endpoint on port 443.

Could you share:

the IIS bindings for both sites
the current URL Rewrite rule
whether the second site should be accessed as:

http://recovery.domain.com:10000

or:

https://recovery.domain.com:10000

That should help determine whether the issue is the HTTPS binding on port 10000, the rewrite rule behavior, or both.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Kaplan, Andrew H 226 Reputation points

2026-05-14T14:09:47.52+00:00

Hello Tom.

Thank-you for your response. The requested information is the following:

Site One:

Type: https IP address: All Unassigned Port: 443 SSL Certificate: recovery_2026

Site Two:

Type: http IP address: All Unassigned Port: 10000

URL Rewrite Rule:

Match URL: Requested URL → Matches the Pattern Using → Regular Expressions Pattern → (.*) Conditions: Logical Grouping → Match All Add condition: {HTTPS} Matches the Pattern ^OFF$ Action Type → Redirect Redirect URL → https://{HTTP_HOST}/{R:1} Append query string → Checked Redirect type → Permanent (301)

The second site should be accessed using the https connection.
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-05-15T07:22:13.9466667+00:00
Hi @Kaplan, Andrew H ,

Thank you, that clarifies the issue.

At the moment, Site Two only has an HTTP binding configured on port 10000:

Type: http Port: 10000

Since the site is expected to be accessed over HTTPS, I would first add a separate HTTPS binding for Site Two on port 10000 and assign the recovery_2026 certificate to that binding.

For example:

Type: https IP address: All Unassigned Port: 10000 SSL Certificate: recovery_2026

Right now, the certificate is only bound to Site One on port 443, so IIS is not configured to serve HTTPS traffic for Site Two on port 10000. Microsoft’s SSL setup guidance also lists creating an HTTPS binding as part of configuring SSL for a site.

After adding the HTTPS binding, I would first test the site directly using:

https://recovery.domain.com:10000

If the site still does not behave as expected after that, the next step would be to review the URL Rewrite rule behavior for requests coming through port 10000.

I would also recommend testing in an InPrivate/Incognito window after making the change, since browsers can cache 301 redirects.
Kaplan, Andrew H 226 Reputation points

2026-05-15T17:29:36.45+00:00

Hello Tom.

I went through the motions of setting up the second site with suggested binding. The settings that I am entering are the following:

TYPE: https

IP ADDRESS: All Unassigned

PORT: 10000

HOSTNAME: recovery.domain.com

SSL CERTIFICATE: recovery_2026

However, when I click 'OK' to apply the settings, a pop-up window appears on-screen with the following message: 'The specified port is being used by a different binding'.
Bruce (SqlWork.com) 85,281 Reputation points

2026-05-17T17:34:19.7933333+00:00

You probably have a http binding which must be deleted.
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-05-18T09:32:26.3566667+00:00
Hi @Kaplan, Andrew H ,

Thanks for the update.

I agree with Bruce’s point here, the existing HTTP binding on port 10000 is likely what is blocking the HTTPS binding from being added.

Since Site Two already has an HTTP binding on port 10000, IIS is not letting the HTTPS binding use that same port. If the second site should now be accessed as:

https://recovery.domain.com:10000

then I would remove the existing HTTP binding on port 10000 for Site Two, then add the HTTPS binding with the recovery_2026 certificate.

The final binding for Site Two should look like this:

Type: https IP address: All Unassigned Port: 10000 Host name: recovery.domain.com SSL Certificate: recovery_2026

After that, test the site directly with https://recovery.domain.com:10000.

Just note that once the HTTP binding is removed, http://recovery.domain.com:10000 would no longer be the expected URL. If IIS still reports that the port is in use after removing that HTTP binding, then another site or process may also be using port 10000.
Kaplan, Andrew H 226 Reputation points

2026-05-19T12:45:40.1366667+00:00

Hello Tom.

It appears the above will not work. I cannot remove the http binding to port 10000 from the second site. The ability to remove that binding is greyed out.
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-05-20T10:37:40.16+00:00
Thank you for checking.

Please try these steps next:

Close IIS Manager and reopen it as Administrator.

Go back to Site Two → Bindings, select the existing http binding on port 10000, and check if Remove is available.

If Remove is still greyed out, try removing the binding from an elevated PowerShell window:

Import-Module WebAdministration Remove-WebBinding -Name "Site Two" -Protocol "http" -Port 10000

Please replace Site Two with the actual IIS site name.

After that, add the HTTPS binding again:

Type: https IP address: All Unassigned Port: 10000 Host name: recovery.domain.com SSL Certificate: recovery_2026

If PowerShell also cannot remove the binding, then the next thing I would check is whether the binding is being controlled by another IIS configuration layer or another site configuration.
Kaplan, Andrew H 226 Reputation points

2026-05-20T13:23:04.6266667+00:00

Hello Tom.

Thank-you for your response. I have been going with generic names for the two websites, but at this point I believe I can give the actual names.

The above steps did not work, as the Remove option in IIS Manager was still greyed out, and the output from the elevated PowerShell prompt came back with the following error:

Remove-WebBinding : Cannot find binding '*:10000:'.

I am starting from the beginning with the SSL Certificate available and assigned to the first site. The URL Rewrite Rule has been removed until this issue has been resolved. The bindings at the time of this posting for the two sites are the following:

NAME: Default Web Site (site one) TYPE: http IP ADDRESS: All Unassigned PORT: 80 HOST NAME

NAME: Default Web Site (site one) TYPE: https IP ADDRESS: All Unassigned PORT: 443 HOST NAME : rorecovery2.partners.org SSL CERTIFICATE: rorecovery2_2026

NAME: rowebconsole (site two) TYPE: http IP ADDRESS: All Unassigned PORT: 10000 HOST NAME
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-05-21T04:04:43.49+00:00
Hi Kaplan, Andrew H,

Thank you for the details.

Since the earlier command did not find *:10000:, I would first confirm how PowerShell is seeing the binding before trying to remove it again.

Could you run this from an elevated PowerShell window and share the output?

Import-Module WebAdministration Get-WebBinding -Name "rowebconsole" | Format-List protocol,bindingInformation,sslFlags

Once we can see the exact bindingInformation value, the remove command can be matched to that output instead of guessing the binding string.
Kaplan, Andrew H 226 Reputation points

2026-05-21T11:51:41.8866667+00:00

Hello Tom. The output from the PowerShell command is the following:

protocol : http bindingInformation : *:10000:rorecovery2.partners.org sslFlags : 0
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-05-22T04:29:55.8566667+00:00
Hi Kaplan, Andrew H,

Thank you for the output. The binding seems to include the host name, so it needs to be removed using the full value:

*:10000:rorecovery2.partners.org

Please try this from an elevated PowerShell window:

Import-Module WebAdministration Get-WebBinding -Name "rowebconsole" | Where-Object { $_.protocol -eq "http" -and $_.bindingInformation -eq "*:10000:rorecovery2.partners.org" } | Remove-WebBinding

After that, you can confirm it was removed with:

Get-WebBinding -Name "rowebconsole" | Format-List protocol,bindingInformation,sslFlags

Then add the HTTPS binding for rowebconsole:

Type: https IP address: All Unassigned Port: 10000 Host name: rorecovery2.partners.org SSL Certificate: rorecovery2_2026

Then test it with:

https://rorecovery2.partners.org:10000

If it still does not load after that, I would first check whether the HTTPS binding now appears under rowebconsole in IIS Manager.
Kaplan, Andrew H 226 Reputation points

2026-05-22T18:39:39.0733333+00:00

Hello Tom.

The above steps worked. I can connect to the https://rorecovery2.partners.org:10000 website. It appears the redirect for the first site, rorecovery2.partners.org is also working without issue.

The URL Rewrite rule is not in place, but the first site has bindings for ports 80 and 443. Regarding that: Should the URL Rewrite be put in place for the https://rorecovery2.partners.org:10000 website?
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-05-25T10:44:00.1633333+00:00

Hi @Kaplan, Andrew H,

Sorry for the late response and thanks for confirming.

Since https://rorecovery2.partners.org:10000 is working now, I would not add the URL Rewrite rule to rowebconsole.

URL Rewrite would only be needed if you want an HTTP request to redirect to HTTPS. Since this site is now being accessed directly over HTTPS on port 10000, no rewrite rule is needed there.

For the first site, if the redirect is already working as expected, I would leave that configuration unchanged as well.

If you still have any issues, please feel free to comment. I'd happy to assist.
Kaplan, Andrew H 226 Reputation points

2026-05-25T15:17:49.54+00:00

Hello Tom.

Per your suggestion, I will leave things the way they are, and thank-you again for the help.

Answer 2

Both sites can work, but the second site needs its own HTTPS binding and (optionally) its own rewrite/redirect behavior.

Key points and steps:

Configure HTTPS bindings for both sites
- In IIS Manager, for Site 1 (port 443):
  - You already have an HTTPS binding on recovery.domain.com:443 with the new certificate.
- For Site 2 (port 10000):
  - Decide how it should be accessed securely:
    - Either keep it as https://recovery.domain.com:10000 (HTTPS on 10000), or
    - Move it to a standard HTTPS port (443) with a different host name or IP.
  - If you want https://recovery.domain.com:10000:
    - Add a new HTTPS binding to Site 2 with:
      - Type: https
      - IP: the server IP (or All Unassigned)
      - Port: 10000
      - Host name: usually blank when using a non‑standard port
      - SSL certificate: select the same certificate (if it matches recovery.domain.com).
- Without this HTTPS binding on port 10000, HTTP.sys will not listen on 10000 for TLS and the site will be unreachable over HTTPS.
Ensure the HTTP (port 80) redirect does not capture traffic meant for port 10000
- URL Rewrite rules work per site and per request, based on the URL/headers, not on the IIS site name.
- If the redirect rule on Site 1 is too broad (for example, redirects all requests for recovery.domain.com regardless of port), browsers may never reach Site 2.
- Typical safe pattern:
  - On Site 1 (port 80), have a rule that redirects http://recovery.domain.com → https://recovery.domain.com (port 443).
  - On Site 2, either:
    - No redirect rule at all, or
    - A rule that redirects http://recovery.domain.com:10000 → https://recovery.domain.com:10000 only.
Example of using URL Rewrite correctly
- URL Rewrite is designed to transform URLs and perform redirects based on rules. For example, a rule can:
  - Redirect http://recovery.domain.com to https://recovery.domain.com.
  - Rewrite friendly paths to internal ones (e.g., /article/342/title → /article.aspx?id=342&title=title).
- Ensure rules are scoped to the correct site and do not unintentionally affect the second site’s traffic.
Test the configuration
- After adding the HTTPS binding for Site 2 and adjusting rules:
  - Restart IIS or recycle the sites.
  - Test:
    - http://recovery.domain.com → should redirect to https://recovery.domain.com (Site 1).
    - https://recovery.domain.com:10000 → should load Site 2 over HTTPS.
    - If using HTTP on 10000, test http://recovery.domain.com:10000 and, if desired, configure a separate redirect to https://recovery.domain.com:10000 in Site 2.

If the second site still fails to load after adding the HTTPS binding on port 10000 and adjusting URL Rewrite rules, verify that the firewall allows port 10000 and that no other service is using that port.

References: