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/...
Related
We have an intranet server that hosts many web applications / web services in various virtual directories all located under the default web site in IIS6. These all just use http connections on port 80 e.g. "http://ourintranetsite/applicationname" or "http://ourintranetsite/servicename" etc.
We have a new web service that we have deployed to a virtual directory under the default web site and it works fine using an http connection. One issue has arisen now that we are starting to use SharePoint Online. We want to be able to call this web service from some client site script on a SP Online page, but it is causing an issue because the SP Online page is using https, so it doesn't like calling a web service over http (IE just puts a warning message in the browser console, but Chrome refuses to make the call at all).
Is it possible to configure just the virtual directory hosting this web service to require an SSL connection rather than setting it at the web site level? We really don't want everything under the default web site to start requiring https, just this particular service. Obviously I could just tick the "Require secure channel (SSL)" option in the properties of the virtual directory, but from what I understand (I've not had to use SSL before), the default port for that will be 443 while the website is using port 80. Ideally we'd just like to be able to get to the service with something like "https://ourintranetsite/secureservice/..." while not impacting any of the existing http applications and services.
No it's not possible to assign a certificate to virtual directory, however when you add a cert to the website all it does makes the site brow sable over https but that doesn't mean that it has to be browsed only over https.
What I meant is you can have site to be brow sable over http and https. Add the necessary cert to the site and make sure you do not check "Require secure channel (SSL)" and it should be good to go.
I installed an ASP.net application on a windows Azure VM (IIS 7). SSL certificate is installed, configured and the application works correctly. I have removed Http binding and http endpoints.
The issue I am having is that if I use the cloudapp.net link (using https), the application still opens with a mismatched certificate.
What can I do to deny any user from opening my application using https://xx.cloudapp.net/x?
It seems really silly that people are saying this isn't the right place for this question, since some of the solutions could be code related. ie: In your application, check the host and if it's cloudapp.net, do a URL redirect.
There's a few different options here but it sounds like what you're looking for is just the ability to prevent someone from viewing the application using that URL.
What I would do is set up a site in IIS that uses Host Header resolution to look for xx.cloudapp.net. If that URL is recognized, do a redirect using the HTTP redirect settings to the https version of your app. Don't bind the SSL port to this site or you'll run into SSL errors like you showed above.
The other option is to leave it out entirely and simply use the Host Header resolution to filter out requests for your site. I suspect what you've done is assign all incoming requests to the only IP address on the system, which is why the xx.cloudapp.net is showing your app and the cert is failing.
This would cause xx.cloudapp.net to fail to show any site at all but I think that might be what you want to do anyway.
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!
I have an IIS7 site that works fine while on the server, however refuses to work from anywhere on the network.
When logged onto the IIS Server itself (with remote desktop) then the website shows fine, as per this link (I used port 801 for this site):
http://localhost:801/
However when attempting to access this site from the network, it refuses to work, giving the generic 'cannot display the webpage' message, while using the following link:
http://<<my IIS server>>:801/
Another thing I have noticed however is that on the network the default page (port 80) of the IIS server DOES work. I.E this following link shows the standard IIS7 page:
http://<<my IIS server>>:80/
Most of the help topics I've read point to it being a firewall issue, however as a test I disabled all firewall settings on the IIS Server, yet it still refused to show.
Does anyone have any other suggestions?
Many thanks
Did you tried with computer name and / or IP Address
e.g: http://192.168.1.105:80/
http://DELL_PC:80/
Run the following tests:
Check connectivity from both computers.
Firewall settings, temporary disable the firewall from all profiles (private, domain, public) if this works, try adding a Port Rule to your firewall allowing incoming connections to port 80.
Also, it'd be important to check the bindings configuration of your website, bindings specify the address the server should listen to for incoming connections, make sure you have 'All Unassigned'.
Reference : Click Here !!
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.