0

We've got two sites with two IPs using only port 80, and an SVN repository using 443 on one of those IPs. When I try to set up SSL for one of the two sites (with the IP that is not in being used by SVN), it refuses to start up because it claims 443 is already in use, even though it should be using an entirely separate IP.

We've got a web server with Windows Server 2003 x64, running IIS 6. We've got two domains that each map to their own IP. Let's say site A maps to 1.1.1.1 and site B maps to 2.2.2.2. SVN is set to listen on 1.1.1.1:443, while sites A and B listen on 1.1.1.1:80 and 2.2.2.2:80, respectively. This works just fine, until I try to set up site B to listen on 2.2.2.2:443, in which case site B will fail to start, as mentioned above. If I stop SVN, then I can start up the web services (including the one on 2.2.2.2:443) but then when trying to start up SVN again, it gives the same basic "already in use" error. But while they're both listening to port 443, they're doing so on separate IPs, which I thought should work.

I've used netstat, and see that SVN is indeed listening at 1.1.1.1:443, instead of 0.0.0.0:443 (which would mean it's listening to all IPs, I think?). It was previously configured to listen on "any" IP, and I thought I would have solved my problem by setting it to only listen at 1.1.1.1, but making that change had no effect. Nothing else is listening to 443. Similarly, the two sites set up in IIS are set to only look for their respective IPs, instead of "any unassigned", and when I set site B to use SSL at port 443, I similarly restrict it to just IP 2.2.2.2.

Considering I can get either the web service or SVN to run just fine, but not at the same time, it seems pretty straightforward that they're conflicting with each other. But shouldn't their separate IPs resolve that conflict?

2
  • Hmm, have you tried to bounce IIS (Start -> Run -> iisreset)?
    – gravyface
    Mar 1, 2011 at 22:39
  • It looks like iisreset has the same effect as restarting it through IIS Manager, which I have tried (when it comes back up, site B is shown with a red X). Mar 2, 2011 at 17:22

2 Answers 2

1

suggestion use port 8443 for SVN, its like a secondary ssl port. It is similar to port 8080 to 80. you shouldnt have any issues assigning port 443 to the website then.

make sure your router sets port forwarding to 8443 for SVN

you can also use SVN+ssh on secure port 22

1
  • That sounds like a good plan; I had considered switching SVN's port but hadn't thought about port forwarding. I need to see if I have the right access to the server's router though. Mar 2, 2011 at 17:30
1

Alright, I hate to answer my own question, but I seem to have come across a fix, though I doubt it's a general solution.

This KB article seems to be referencing my exact problem:

There are two Web sites in IIS 6.0. Web site 1 is bound to 10.10.10.2:80 for HTTP traffic. Web site 1 is also bound to 10.10.10.2:443 for SSL traffic. Web site 2 is bound to 10.10.10.3:80 for HTTP traffic only.

In this scenario, when you use the netstat command to view the ports on which the computer is listening, you may notice that IIS 6.0 is bound to port 80 and to port 443 on both IP addresses.

From their solution, I had to add a new value to the registry. So, under the key HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, I had to add the DWORD value DisableEndpointSharing, and set it to 1. The second part of their solution didn't apply (running httpcfg query iplisten told me the IP Listen list was already empty).

After adding the above registry value and restarting IIS, site B now showed up under netstat as being bound to 2.2.2.2:443 instead of 0.0.0.0:443, and I could start up SVN bound to 1.1.1.1:443 without any problems.

So at least in this case, I suppose it was just a known issue with a workaround that somehow applied to our configuration.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .