If I have a valid signed SSL cert, I can see the CN (common name) attribute does not have localhost or the LAN IP - but I do not see an SSL error "ssl_error_bad_cert_domain" when I connect to https://localhost. Surprisingly,I have seen this error (only in some cases) even if I connect to the public IP instead of hostname.
Can someone please help me with a reasoning ? I wonder if DNS (or say hosts files) would tell this resolution to the browser !
Related
I ran a website with Nginx and NodeJS on Lightsail.
When I go to my mywebsite.com, my website is accessible and is secure. However, when I try to enter the public IP for that website, Nginx returns a 404 error page. The website is certified by LetsEncrypt.
I do manage to access the IP address on the browser by adding http:// before the IP address. However, when I normally go to my IP address, Nginx returns a 404 error. Why is this so?
I'm fine with the IP being not accessible. But my CDN is not working because of it. I think it needs to be accessible and not return a 404 page?
Why do I go about diagnosing and solving this problem?
Thanks in advance.
The Host: header identifies the hostname/domain-name used by the browser to access a website when the webserver is serving multiple websites on the same TCP binding (IP address + port number + protocol). The webserver then uses that to determine what content to serve.
Web-browsers generate the Host: header from the URI in the address bar.
When you access http://1.2.3.4/foobar your browser sends this request:
GET /foobar
Host: 1.2.3.4
When you access http://example.com/foobar your browser sends this request:
GET /foobar
Host: example.com
When you access http://www.example.com/foobar your browser sends this request:
GET /foobar
Host: www.example.com
When you access https://example.com/foobar or https://www.example.com/foobar the requests are the same, but the underlying HTTP connection is wrapped in a TLS (formerly SSL) connection. Things get complicated with HTTP/2 (SPDY) and HTTP/3 (QUIC) so I won't explain how those work.
In your case, you need to edit your nginx configuration to add another binding to your website that maps http://<IP-address> to your website, as well as https://<IP-address>. You need to check your web-application's code to ensure that it can handle requests using unexpected Host: headers - you can also configure nginx to modify the Host header for incoming requests to your usual header.
If you're using HTTPS then you'll need to add your IP address as a SAN (Subject Alternate Name) to your TLS certificate - which is generally a bad idea because IP addresses change and LetsEncrypt doesn't provide certificates for IP addresses anyway so this is moot.
For dev purposes and when you're running nginx locally (i.e. http://localhost) then you no-longer need a TLS certificate for localhost because since early 2020 Chromium-based browsers now recognize http://localhost as being a "secure" website even though it's over http:// and not https://:
https://www.chromestatus.com/feature/6269417340010496
https://bugs.chromium.org/p/chromium/issues/detail?id=589141
https://bugs.chromium.org/p/chromium/issues/detail?id=691930
For an immediate workaround, you can use a browser-extension to override the Host: header when you're accessing a site by IP address.
e.g.:
https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj?hl=en
https://chrome.google.com/webstore/detail/modify-header-value-http/cbdibdfhahmknbkkojljfncpnhmacdek?hl=en
https://chrome.google.com/webstore/detail/requestly-redirect-url-mo/mdnleldcmiljblolnjhpnblkcekpdkpa?hl=en
/etc/hosts file has an entry in my development server 10.xx.xx.162 server-dev.xxx-intra.net. ping to server-dev.xxx-intra.net is successful.But when I am trying to access from the browser - https://server-dev.xxx-intra.net, it throws server-dev.xxx-intra.net's server IP address could not be found. I understand that it is not able to resolve that name to IP but shouldn't /etc/hosts entry have taken care of this? Please let me know if I am missing something.
I have create a very simple site in IIS Server version 8.5 using port 85. The site only have one index.html that shows the word "test" the page. When I access the site inside the server I can access it successfully: "http://localhost:85" is working.
Trial 1:
I try accessing it from my computer that is connected to the same network with the server using url "http://servername.test.com:85", the browser goes loading for long time and finally ends in with error "Connection Reset".
Trial 2: I try updating the Site Binding's Host name with our "Vanity Name" and "IP Address", but after this I still get a "Connection Reset" error.
Trial 3: Now I also check for opened ports using netstat, and I can see that port 85 is open. So I don't know why I'm getting Connection Reset error
Trial 4: I added Connection timeout value on the settings. But still I'm getting Connection Reset error.
Please kindly help with advise how to fix this Connection Reset issue. I can't find what is the reason behind this issue. Thank you in advance.
According to your description, I guess you may not bind the right IP address for the servername.test.com domain or use the wrong ip address bind with servername.test.com domain.
I suggest you could firstly try to use the server's ip address to access your web application to make sure you firewall setting and IP setting is right.
If your client server and the IIS server are in the same domain and you have installed an DNS server, then you could access the web site by domain. Details about how to set the DNS server, you could refer to this article.
If you just want to test, you could try to modify the hosts file in the C:\Windows\System32\drivers\etc path in your client server.
For example:
127.0.0.1 www.example.com
I've found the solution. I issue was caused by Firewall enabled on the server and the ports are not opened by the Network Administrators. So I just opened the Ports that I will be using and it works now. Installing IIS Failure Tracing help me catch the error also. Thank you for all those who answered.
I have added a website to IIS with a binding hostname of richard-danvers.dev assigned to port 80
I have then added an entry to the hostfile with the public ip address of the server and the host name:
51.141.98.202 richard-danvers.dev
I have also tried
127.0.0.1 richard-danvers.dev
this results in ERR_CONNECTION_REFUSED
when I ping the hostname I can see any changes I have made in the hostfile (e.g. 127.0.0.1) but it still does not work when trying to navigate to the site in a browser.
and I have also tried with the actual DNS record I have pointed to the public IP (this returns a ERR_CONNECTION_TIMED_OUT and ping resolves but does not get any successful pings)
none of these seem to allow my website to be accessed. When I enter a binding without a hostname I can hit the website under localhost fine so can't understand what I've done wrong/missed.
Because I am using a .dev domain the ssl certificate had to be set up and configured in the bindings to allow the hostname to be hit.
As pointed out in my answer to Hostname / IP doesn't match certificate's altname Node.js does successfully verify TLS certificates on host names when the requested host name is given as the Common Name (CN) of the certificate.
Request : localhost
Common Name: localhost
=> Success
Now when I try the same for an IP address, verification fails:
Request : 192.168.178.31
Common Name: 192.168.178.31
=> Fail
It only works if I specify the IP address as Subject Alternative Name (SAN):
Request : 192.168.178.31
Common Name : 192.168.178.31
Subject Alternative Name: 192.168.178.31
=> Success
As described in the answer to IP address as hostname (CN) when creating a certificate? (HTTPS hostname wrong: should be <ipAddress>),
using IP address in certificates is not recommended [...].
As an alternative it is suggested in the answer to How are SSL certificate server names resolved/Can I add alternative names using keytool? to add IP addresses as SANs (which in turn works in Node.js).
Now my question is: Not recommended does not mean wrong or forbidden. Is there any specific reason except being not recommended that Node.js does not support IP addresses in CNs, or why it would be a risk (security, whatever, ...) if it did?
The implementation is merely compliant with the HTTPS specification:
In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
When I said "not recommended" in the answer you quote, it was more about using IP addresses in general when using HTTPS. Some browsers let you get away with it, but I also quoted the spec there, which does use the word "must". Needless to say the RFC is more authoritative than any answers you'll find here.