I have a ASP.NET MVC site set up in IIS7 on Win2K8 with a single SSL binding on Port 443. The team in charge of the server only has port 443 open for security reasons, but this shouldn't be any issue because that's the only binding I have and I'm not making any regular HTTP calls on port 80.
When I call my site, my main login page (using forms authentication) comes up in the browser (over HTTPS) which looks fine. However, as soon as I try to login I get the following error:
[SocketException (0x274d): No connection could be made because the target machine actively refused it 10.x.123.123:80]
Ok that is the correct IP assigned to the site, but I'm not making any calls on port 80. Why would I get this error if all I need is a SSL binding on port 443? Am I required to have port 80 open as well? I'm not making any calls internally that use port 80, unless MVC is doing something I'm unaware of that requires port 80.
When digging into the code it turns out that our service turned around and made additional REST calls to other parts of the same service using a HTTP url, thus causing the error.
Since I configured IIS to only allow SSL traffic and I had internal calls to a HTTP URL the error was generated. The root cause was that I forgot we were making RESTful calls within the code and those URLs had to be updated to their respective HTTPS counterpart.
Related
I know port 80 is one of well-know-port, but I am confused that if I build the website server process on other port except of 80, would it works when other client try to access this website server?
Port 80 is the default port for http. So connecting to http://domain would in essence send you to http://domain:80 (by default).
Port 443 is the default for https and would work the same way as stated for http above.
Any other port would require the you to do url:port to connect to. There are definitely ways to get around this (like forwarding) but I don't see the need for it and I think it causes more issues than anything.
You would also need to make sure that the new port is open, forwarded and can receive connections.
(Source for the first 2 paragraphs https://developer.mozilla.org/en-US/docs/Glossary/Port)
I have 2 sites running on the same machine, a client and an API.
Let's say the computer's IP is 10.10.10.10.
The API has a default page when you browse to it, the rest of the API is under 10.10.10.10/api.
The API has HTTP binding to port 80, and HTTPS binding to port 443.
The client has HTTP binding to port 8080, and HTTPS binding to port 64300.
Both HTTPS bindings use a self signed certificate I created via IIS manager.
Both sites have a HTTP to HTTPS redirect using "URL Rewrite".
When I try to browse either one of the apps, it works fine (gives the warning in the browser that you can skip).
When I do some action in the client which involves a HTTP request to the api using one of the following calls I get an error:
http://localhost/api/someMethod
http://localhost:80/api/someMethod
https://localhost/api/someMethod
https://localhost:443/api/someMethod
https://10.10.10.10/api/someMethod
The exception includes this error:
"The remote certificate is invalid according to the validation procedure"
I tried using the method described in this link (add the self-signed certificate to the Trusted Root Certificate Authorities folder) but it won't work.
Help please :D
found the answer.. posting if anyone else will get stuck on it.
It's pretty weird but the only thing that worked was to make the localhost http(s) request using the HOST NAME.
example:
https://the_name_of_the_computer:443/api/someMethod
We use an Apache HTTP server with a Websphere Application Server 8.5
Requests to HTTP servers work on default port 80
I have configured port 2021 on http.conf + in default host in Websphere and everything works. The only 'problem' i have is that we need port info in the URL.
http://oursite/index.html works
http://oursite/myApp.jsp doesn't work
When i add the portnumer to the request it works.
I understand that this extra port is needed to tell HTTP server that this request should be forwarded to Websphere. But customers are complaining that the port we used is blocked by their firewall and some customers refuse to add this port to give access.
Now i tried to add port 80 to the Websphere config (default host) and this seems to work.
Is it really needed to config an additional port ?
*:80 is in the "default_host" by default. Whatever host and port your clients will use to address the proxy must be present in the virtual host that your application is deployed to -- otherwise it won't be handled by the WAS Plug-in.
It sounds like someone removed that *:80 alias from the default host, mistakenly thinking it only needed to be there if the application server explicitly listened on port 80. That is misguided.
I have multiple sites running on my IIS, now for one of the websites (SiteB) we need to support ssl requests. I have enabled it editing bindings for the website, but the problem is when I selected protocol SSL editing bindings HostName field is disabled, being unable to set hostname to respond to https request, this causes that all sites of my IIS if are requested with https:// loads web site of siteB.
For example my bidings are the next
Site A
IP Port HostName
* 80 www.sitea.com
Site B
IP Port Hostname
* 443 www.siteb.com
* 80 www.siteb.com
If I type https://www.siteb.com in my browser it works correctly, but if I type https://www.sitea.com in the browser, siteb webpage is loaded with the hostname of sitea.
How Can I make that only https://www.siteb.com responds to https requests on my IIS?
I have tried with command appcmd too but It't doesnt work.
appcmd set site /site.name:{sitB} /bindings.[protocol='https',bindingInformation='*:443:*'].bindingInformation:*:443:siteB.com
Thanks for your help.
The Root Problem
This unexpected behavior isn't because of IIS so much as it is because of the web encryption protocols.
The two major web encryption protocols are SSL and TLS. Both of these protocols negotiate a secure connection before passing any request information to the server. This means that, on secure requests, servers don't actually learn the hostname until after the secure connection is made.
An extension to TLS and SSL has been created to address this limitation. It's called SNI (Server Name Identification). The problem is that this extension needs to be supported on both the server and client machines. Currently the client browser support is somewhat spotty. See the SNI article for a browser list.
IIS's Handling Of The Problem
It is because of the above mentioned hostname limitation that IIS doesn't allow you to bind hostnames to HTTPS bindings. There is no way for IIS to route HTTPS requests to a particular hostname since it doesn't know the requested hostname when it first begins to negotiate the connection.
Once IIS has negotiated a secure connection with a client and learns that their requested hostname is for a site other than the one with the HTTPS binding (e.g. a request for https://sitea.com) IIS can either return a failure code or try to fail gracefully. IIS chooses the latter and tries to fail gracefully by serving up the site with the HTTPS binding even though the user is requesting a different site.
Solutions/Workarounds
Create a rewrite rule to redirect all HTTPS requests for nonsecure websites to HTTP.
Upgrade to IIS 8 to use the SNI extension. Then ask visitors to upgrade to browsers that suport SNI.
Have your secure site return an error message when it receives a request for a different domain.
Bind by IP address instead of hostname since IIS can route HTTPS requests by IP address
References
Most of my information came from the Wikipedia article on SNI
We run webservers with multiple sites requiring SSL with no problem.
If I understand your problem correctly - you'll need to set up a binding instead of a host name - which won't work. So, for each SSL-enabled site we host, we require a distinct external IP address. Then, enter that IP address as the binding when setting up the site in IIS.
We have a Win 2008 server running IIS7. The webserver runs several sites, one of which requires SSL for its e-commerce / data-capture components:
www.domainA.com :80 & 443
www.domainB.com :80
www.domainC.com :80
www.domainD.com :80
I have installed a certificate for domainA and added an HTTPS/443 binding for the www.domainA.com website. However, if I try to access https://www.domainB.com, I am shown the content from the domainA site.
How can I prevent all sites using the 443 binding from domainA? When I add the certificate to the binding, I am unable to set the hostname. If I use appcmd to set a hostname, the site gets 2 bindings and access via SSL doesn't work.
Only domainA should allow access on port 443 and other sites should refuse the connection.
Thanks
James
SSL starts connection BEFORE any HTTP header is sent - so clearly the server has now way of distinguishing what domain this connection is for until SSL connection is established.
Your binding is correct - the other sites are NOT bound to port 443... but by the time the SSL connection is established and the first HTTP header is sent it is already on the IP address (the name has been resolved via DNS).
As to a solution:
To circumvent what you see you need to bind domainA.com to a different IP address than the rest (and modify DNS accordingly).