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 22.214.171.124 and site B maps to 126.96.36.199. SVN is set to listen on 188.8.131.52:443, while sites A and B listen on 184.108.40.206:80 and 220.127.116.11:80, respectively. This works just fine, until I try to set up site B to listen on 18.104.22.168: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 22.214.171.124: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.
netstat, and see that SVN is indeed listening at 126.96.36.199: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 188.8.131.52, 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 184.108.40.206.
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?