I developed an FBConnect web application using C# .Net Framework 4.0 recently. Tested with my UAT server, everything just works fine, I'm able to login with my Facebook account, and perform all operation.
Unfortunately when I deploy the same code to my client's production environment, the FBConnect return "unreachable network 69.171.229.24:443". After several investigation, notice the port 443 is blocked! And due to corporate policy, this port is not allowed!!
Is there alternate way I can tweak my facebook app settings NOT to authenticate via port 443? instead of rewriting my code?
Please advice.
No, there is no alternative.
Port 443 is for secure HTTPS connections using TLS and SSL. Facebook, quite correctly, restricts access to their authentication mechanism to this port: (as far as I know) there are no alternative mechanisms that use a different port or an insecure login on port 80.
Check with your client to see if there's an proxy server that can be used for HTTPS connections.
Otherwise, request that your client opens that port.
Related
I haven't found much discussion about this...
Most signalr samples I have seen would send and receive via a designated port like 5000 or 8080
I have a need for chatting in my app. My asp.net backend site does more than just handling messages between users, so it doesn't make a difference for me to host another page for that in the site my iis.
I understand the difference of having the signalr self-hosted or hosted normally in iis... If I have it hosted by iis, so my users will access the page normally without a port, would that make a difference? Is there something internal in signalr that is preferring the use of a port? What are the pros/cons of using ports with signalr?
SignalR has no preference for a specific port. When no port in specified in the URL then the port is implied from the protocol, e.g. HTTP uses port 80 and HTTPS uses port 443. So there is no concept of SignalR without a port.
I would think that the main reason for using SignalR on a different port than the rest of your site is that you can host SignalR independently of your main site without any interference in URL's etc. On the other hand, using a non-standard port may give you problems with restrictive firewalls that only allows traffic on port 80 and 443 to pass. When using a different port for SignalR you also lose the ability to use relative URL's to specify the SignalR endpoint.
I've developed a web app, which uses HTTPS and which works fine when I access is it (live). Yet some customers, who use proxy servers, can't access the site. I already tried to use a real certificate (a cheap one and only a trial, but yet valid), but that didn't help.
Everytime one of these users tries to access the site the browser tries to load it until a timeout occurs. One user even was shown an authentication (but I'm not 100% sure if this was due to a proxy, still waiting for response from the customer)
For which reasons can this happen and what can I do about it?
I'm using IIS, ASP.NET (C#) and JS. Sideinfo: The URL contains a port, the internal structure of the network the IIS is running in (not mine) doesn't allow it otherwise.
443 is dedicated port for HTTPS connectivity. Add type 'HTTPS' with default port 443 in Site bindings of hosted site directory. Check after whether SSL is enabled or not? in IE(browser)->Tools->Internet options->Advanced->Security.
If the HTTPS port in your web app's URL isn't port 443, you'll have a problem with corporate proxies that don't like non-standard HTTPS ports.
i.e. I hope your URL looks something like this: http://example.com:443/...
We have deployed our website to the live webserver, Windows Server, IIS 7.5. Website asp.net, .NET 4.5
I have configured the website bindings to allow https requests for this website.
Asked the hosting provider to open up the port 443.
I can access the website over internet with port 80, no issues at all. (http://mysite.com)
But I can not access via https, (https://mysite.com).
But I can access the site via SSL from the server itself, that means SSL configurations are fine.(https - localhost)
But I can telnet (telnet mysite.com 443), it responds to GET request via telnet.
I have rechecked the certificate and changed it to a self-signed certificate, issue is still there.
These requests not being tracked in IIS logs as well, seems like the request is not reaching IIS. Hopefully something goes wrong before it reaches the server.
But, when I access the website as http://mysite.com:443, it works.
I m bit confused with this behaviour. Obviously the port 443 is open by the hosting company. But something is wrong with requests over HTTPS, which is supposed to send a request to port 443. Please help.
Because your site is working when you access http://mysite.com:443, I am almost sure that you created wrong binding on IIS. Instead of selecting https from combo box you selected default http.
There is a tutorial on how to do this on youtube: Changing IIS 7.5 Bindings by David Johnson
You've establish that the port is open and the hostname binding is there, otherwise http://mysite.com:443 would not work. Its the SSL part that's not working, hence you can connect directly by port and telnet (port 443 but not SSL) but not a browser via https. It's only a browser connecting to a https url that will expect SSL.. I'm pretty sure I've had the same issue, but cannot recall the exact cause but it was definitely related to an invalid SSL configuration or SSL binding.. The behaviour was like there is no connection, nothing, which is unusual, its the bad config causes the browser to abort the connection. If I remember what, I'll update or comment below.
So you can access the site using https://localhost? Your question is not quite clear on this point... what is the exact URL you are using? If it's https://localhost, that is actually an indication that your certificate is configured incorrectly. You seem to be interpreting this as an indicator that it's working OK and that is not the case. The domain name is tied to the certificate and SSL will work only when accessing the site using that domain name. So if it works for "localhost", something is wrong.
Finally I found the solution. Issue was a setting in the load balancer of the hosting provider. I have asked the question from them and they have figured out the issue. Anyways it was a good learning curve for me. And this knowledge is going to help others.
The firewall was already allowing both HTTP/HTTPS, which is why we could telnet through and run a GET / and still pull down content from the 404 page of the IP address.
It appears there was a certain profile applied to the HTTPS configuration in the load balancer which would only work for HTTP, so they have disabled that.
When they set this up for HTTP and HTTPS they were not able to test HTTPS, because to do so would require an SSL certificate in IIS - which it appears we have already provided.
Thanks everyone for your help on this!
In our production environment a website runs under HTTPS with SSL terminating on a load balancer and passing traffic to the IIS servers as HTTP.
There are various in-house and 3rd party components and controls within the site and some of them use mechanisms similar to the .NET System.Web.HttpRequest.IsSecureConnection property which simply queries the HTTPS server variable to return its result. As the connection into the web server from the load balancer is HTTP, these methods return the incorrect value and cause some components to fail. For example, a component might direct the user to a HTTP URL instead of HTTPS for a JavaScript file and cause the browser not to load the mixed content.
In order to debug these components and to develop a workaround, I need to recreate this scenario on my development machine. My question is Is there an easy way to simulate an externally terminated SSL connection for the Visual Studio / IIS Express development environment?
I've found a way using Port Forwarding Wizard.
Create a single TCP mapping with Listen Port set to a spare port (e.g. 443), destination as localhost with web server port (e.g. 80). Leave everything else as default, but go into SSL Encryption and generate a Root Key and Certificate in CA Center. Once done, select Enable SSL Encryption and select Server. Generate a Private Key file, Cert Req file and a Certificate and then bob's your uncle, you get terminated SSL forwarding to your local IIS Express server: Simply Start your port mapping and then connect to https://localhost with your web browser (specifying the port if it's not 443).
Is it possible to have a FTP server using SSL on a application server that does not use SSL?
How would you setup an ASP.NET 2.0 to consume a SSL certificate?
This certianly sounds possible but is it advisable, is it good practice?
The choice on using SSL us made on a per connection level, usually determined by the IP port being used (i.e. will be set up between client and server before any application code involved).
The same service/content could be set up on multiple ports each with a different choice for SSL.
The certificate is per host name, but servers can generally support appearing under different names.
To use SSL with ASP.NET takes nothing special, it just works once the IIS web site is configured to support SSL (or to require it: when connections to port 80 for HTTP are redirected to the SSL port); this choice can be made on a per folder basis.
FTP is at the application layer, and SSL is lower, at the presentation layer. The SSL sessions are on a per connection basis. Take a look at the Wikipedia page. The SSL connection is established before anything happens with your application. Your FTP server probably isn't running inside your .NET application server, is it? You should be able to setup an SSH server listening for SCP connections separately. If it really does run from inside your app server, you should be able to listen on a separate port for the SSL connection.
Short of any of that, heres a good link for configuring SSL in IIS. You don't have to make the certificates mandatory. That way you can allow unsecured traffic and secure traffic if that fits in with your application model.
While protecting an application with SSL is always a good idea, it is technically not trivial.
Having a web application protected with SSL requires the webserver to be reachable on a new port (443/https instead of 80/http). This has to be configured "system-wide". Also, there may be only one certificate per IP-address, which is often a problem when hosting multiple domains on the same server.