I use my home network (ATT U-Verse) to serve my ASP .NET website on a Windows 8.1 Pro machine with IIS 8.5. Because Chrome requires https for doing audio recording, I want to move to https. I followed the instruction video at https://www.netometer.com/blog/?p=1758 , and everything corresponds (IIS showing that I have a certificate in the bindings and an entry for port 443) until I test the actual https link in a browser (on the server itself, on an other machine on the home network, or externally via my phone with data), which gives me a "This page can’t be displayed" or equivalent message. I added port 443 to the Norton firewall rule I already had. The http access still works, however. Netmon 3.4 shows no TLS or SSL traffic. I also tried disabling the Norton firewall temporarily. This leads me to believe that the problem is that either the ATT NVG510 router I have is blocking port 443, or that ATT itself is blocking it. Looking at the router settings on the Packet Filter page, it seems none of the default "Drop" rules are enabled, and there is an "Enable Packet Filters" button. Do I specifically have to set up a "Pass" rule?
Does anyone have any ideas on what I could do? Can I actually do https on my home server? My web site is www.jtlanguage.com . Sorry if this is the wrong place to put this. I'm a programmer trying to do some IT.
Thanks.
-John
Turns out I wasn't doing port forwarding. For NVG510 users this is done by going to the router page in the browser to firewall->NAT/Gaming page and adding a hosted application referencing the HTTPS service and the web server machine name.
Related
I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?
Currently I am trying to host my own web-server. Unfortunately, I am running into a big issue with port forwarding. I have already routed the URL to my IP, and the web server is running on port 80. However, when trying to access my IP/website on port 80 (which is forwarded on my router) through any browser, the page that comes up is my router's web-based setup page. Apparently, its operating on port 80 as well, and I can't seem to find a way to get around it (when setting the Apache server to say, port 8080, the website works fine, but as there is no way to hard-code a different port into the URL, this really doesn't help). I'm definitely a newcomer to web-hosting, as this is my first attempt, so hopefully someone can point out a solution? The router model is a LuxulXen XWR-1750, if that provides any guidance.
You will need to setup Port Forwarding on your router so that external access on port 80 will be forwarded to the ip address of the PC running Apache.
See portforwarding.com for help on how to setup your router and what port forwarding means.
Additional Suggestion
If thats not the problem then you might check that the router is configured so it does not allow external Administration. If this is set to allow external administration maybe thats why you are getting sent to the admin config login screens rather than routed to the PC running Apache.
We are trying to setup the Worklight Server for production, which is behind a reverse proxy that will help manage the SSL certificate.
What this means is that, when the user hit the domain, say https://mydomain.com:443, the proxy will automatically forward the request to the Worklight Server on port 9080.
After the setup is done for the reverse proxy following this guide, the installers.html page is working well. However we notice that when we try to access the console using https://mydomain.com:443/appcenterconsole, the user gets redirect to http://mydomain.com:9080/appcenterconsole/console.html instead and this is causing problem.
I searched around and found this link Worklight Console redirects to port 9080, which is similar to the problem i'm having. Is there a way for me to configure the Websphere Liberty Profile so that it will use the reverse proxy URL as the redirection URL?
I notice also that the index.html file in the appcenterconsole.war is using the meta refresh method to do the redirection. I'm tempted to change it to use a full URL, but then i also notice that the same issue happens when we go to the login.html and perform login. (Whereby after login, the page redirects the user with the 9080 port as well).
Any pointers or idea are welcomes. The Worklight version used is 6.1.
Thank you.
EDIT
The network setup in my environment:
Proxy Gateway (with SSL cert) configured to connect to Worklight Server for port 9080 whenever a connection with port 80 or 443 is received. Therefore:
https://mydomain.com:443/appcenterconsole -> will be mapped to http://worklightserver:9080/appcenterconsole
The mapping is done internally between the proxy and the worklight server.
When we type the full URL on the browser, ie. https://mydomain.com:443/appcenterconsole/console.html after i login, the console works fine.
Have you set up the JNDI entries detailed here?
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.installconfig.doc%2Fappcenter%2Fr_ac_appres_endpoint.html
I'm in the process of creating a website using the ASP.Net MVC 4 framework. I'm having difficulty getting SSL working with that (or any sort of basic) site.
I purchased an SSL certificate for the domain in question (let's just call it "example.com"). I have gone into IIS, and have configured the https binding for the Default Web Site for port 443. If I open the non-SSL version of the site, it works. (In this case, the site is the stock, basic IIS start page). If I attempt to access the site over https, it times out and fails to display the page.
I've verified using netsh that port 443 is open, and that there is nothing else listening on the port. I've double checked to make sure that Windows Firewall is allowing traffic on port 443, and it is. If I fire up Wireshark and listen for traffic on port 443, then attempt to access the web page, I get the following:
I'm not an expert at interpreting these results, but it would seem that something is still blocking the outbound connection. Again, the regular http web page loads fine, but the https version of the same page times out.
I'm about at my wits end trying to figure this out. Any ideas what might be going on here?
Either something is blocking the connections on port 443 on their way to the server or something is blocking the responses. From the wireshark screenshot I see that the server and your client are in separate networks, so there is obviously at least one router in between, maybe other firewalls too. You might check with traceroute or tracepath how far your request travels (e.g. specify port 80 in one try and port 443 in another try and compare) and where the filtering device might be.
This took a bit of digging, but I finally figured it out.
It would appear that, by default, https access to an Amazon EC2 instance is blocked. This explains why it didn't matter what I did in IIS, it wouldn't work. This would also explain why having the correct binding, having the proper ports open on the firewall, and anything else I tried didn't work. It had to do with Amazon, and how they've got things configured on their end.
To enable traffic on port 443, I did the following:
In the Amazon web console (https://console.aws.amazon.com/ec2), click on the Security Groups link on the left
Under the security group that your instance is running, set up a new Inbound rule to allow HTTPS traffic from any IP.
Set up a new Outbound rule to allow HTTPS traffic to any IP.
It wasn't necessary to delete/recreate/restart the instance. As soon as I applied the rules, I tried hitting the https site in my browser on my local machine, and it worked.
Steffen, thanks for the help.
(Related: HTTPS setup in Amazon EC2)
I am working on Windows Server 2003 (IIS6), which has two asp.net sites running in seperate app pools. One of the sites has an ssl certificate installed and was running fine on https. The other site has no certificate and does not require https
The problem I have is that when I publish my app from vs2005 to the site with ssl the https urls stop working and I can only use http. The error I get is as follows
From Google Chrome: Error 104 (net::ERR_CONNECTION_FAILED): The attempt to connect to the server failed.
From IE7: Internet explorer cannot display the web page, could be unavailable, dns is not reachable etc
The strange thing is the first time this happened, https eventually became available but I don't know what triggered the availability but when I published an updated assembly to the bin folder of the site which does not require https, the OTHER site became unavailable on https again
Help much appreciated!
UPDATED: Thanks for the suggestions but it turns out that the firewall was not open on the ssl port
Check if the firewall port for SSL (443) wasn't accidentally closed 443. ;-)
If both webs use the same IP address, make sure, that only the web with the certificate uses the SSL port 443 (first property page). The input field should be empty for the insecure site.
If that is not the problem, you could try to debug stopping the web without certificate and restart the web server.