I am currently encountering a very strange error. I am using Google Chrome and Firefox for testing on my local computer. On my root server there's Debian installed and as panel vesta control panel.
I've associated my domain with the panel and everything's being fine except one thing: I randomly can't get to my webserver by entering my domain with https://www.domain.tld/. Sometimes (very rarely) it's working, but it's most likely to be not working.
On my other Windows root server I can access the site easily with the domain (using a Cloudflare SSL certificate), but my home network (at least my computer) isn't able to.
I don't know what to do...
Maybe check if this page is working for you:
https://www.mrxidevelopment.de/img/img1439586803_2015.png
(This is a picture of this topic)
Regards
Related
I encounter the problem when I try to access the website of my software engineering uni course. On my desktop (Win10), phone and tablet (both Android) I receive a "SSL_ERROR_NO_CYPHER_OVERLAP"-Error when trying to access the site.
The error appears regardless of browser, it seems to be system-wide.
Interestingly enough I can access the site on my laptop (Win10 + Manjaro) and could also access it on my desktops Manjaro partition. I could also access it on my phone in the uni-network - but not using mobile data.
However I am not sure, whether mobile data is to blame, as I logged in with my firefox account before receiving the error. Naturally I assumed it may have something to do with my firefox-preferences, but i am using the same account on my Manjaro Systems as well as the Win10 partition of my laptop. Besides me, none of my friends, except one have this problem.
I ran the URL through multiple different SSL-Checkers and every one of them encountered problems regarding the SSL-certificates. As the problem occures in different networks I can also rule out some router-settings of my home-network being the cause. Have you encountered such an error before and is there anything I can do on my own or is this an issue I should take up with my course-instructor and ask him to take a look at his server?
As it turns out the browser plugin "HTTPS Everywhere" was causing the problem.
The error occured in different browsers without the plugin because I copy-pasted the https URL. The issue appeared on my phone because of the shared browser history, which autocompleted the URL to the https version. The plugin is not installed on my Manjaro's Firefox, which is a bit strange as I though it would be shared.
Additionally, on Manjaro, Firefox does not suggest the https version of the site for auto-completion - maybe it favors sites opened on the specific device over sites opened on different devices. Either way, it works now.
I was working on a website on my local computer (mac OS High Sierra) and had put some redirects in the websites .htaccess file (in order to get images from the remote server instead of downloading them). After this it seemed that I could no longer access the website from my Chrome browser. Chrome would answer to any URL leading to the remote server with ERR_CONNECTION_REFUSED.
I tried other browsers on my computer such as Firefox, Chrome Canary, Chromium and Opera. None of them could provide a connection.
Next I checked with a different internet access via TOR-Browser on the same computer whether I could access the website, and it worked.
Next I checked via Terminal whether I could connect to the remote server with ping, nslookup and traceroute. All connecting to the server as expected.
I googled up possible solutions to this problem but could not find one so far. I had read that resetting the DNS cache could help and tried sudo killall -HUP mDNSResponder but it did not.
I did not edit the /etc/hosts file; a restart of the computer did not help; a reset of the .htaccess to the previous state did not help; resetting the caches in the browsers did not help.
How can I access the remote website from my browsers normally again?
EDIT1: Related question: Failed to load resource: net::ERR_CONNECTION_REFUSED for only selective images from instagram API
EDIT2: After about one day I was able to access the remote website again with no further incidents of ERR_CONNECTION_REFUSED even after putting the redirects into the .htaccess file. So it seems to me of being some sort of caching on my computer which prevents the browsers from accessing the remote website. However I have no clue what caused the error message in the first place and what kind of cache it might be.
Shortly after EDIT2 when I was able to access the remote website again, the ERR_CONNECTION_REFUSED appeared again - this time I tested another device with the same internet connection and I had encountered the connection error too. Now I believe it has something to do with the router and/or it's firewall - not the ISP since I could connect to the remote website with shell commands (named above). The image requests to the remote website seem to cause the router to block further access from browsers, probably as a security measure similar to the situation in this article https://www.cnet.com/forums/discussions/can-t-access-a-specific-website-going-thru-my-router-274637/
I currently test NTLM authentication with Apache 2.4 on a windows machine, locally. All work fine. If i open a demo site http://localhost/authfoo/text.php, the site will load without an authentication dialog in every browser. The test.php script get all required authentication data automatically from the current windows user.
So far so good. Tested with Internet Explorer 11, Chrome, Firefox and it works. Only Microsoft Edge open up an authentication dialog and i must enter credentials. All what i see in this dialog window is that the title show my computername instead of localhost. This indicated that Edge use the computername as internal domain, and that is for sure no intranet domain, like localhost is.
There is something for edge that is a so called LoopbackExempt. With that you can allow localhost to be threaded as an intranet site. This setting also not helped me. https://developer.microsoft.com/en-us/microsoft-edge/platform/faq/#how-can-i-debug-localhost
However, when i manually add http://15031489-nb.cstp.intern/ to intranet sites via settings in Edge, than it work when i use http://15031489-nb.cstp.intern/authfoo/text.php without an authentication dialog. But http://localhost/authfoo/text.php still show that authentication dialog.
Btw, http://localhost is also added to intranet sites, just to make sure everything will be treated as an actual Intranet Site.
So, i have no idea of how i can get this thing to work in Edge also, like every other browser already does, even IE 11 work without flaws.
I've been searching this problem for a while and found this answer from the microsoft developer community:
Microsoft Edge doesn't allow integrated Windows Auth over loopback as
a security mitigation to prevent breaking the browser sandbox. The
only workaround offered by the team is to use the FQDN while
debugging.
(Source)
So you will have to use the FQDN instead of http://localhost/, which is http://15031489-nb.cstp.intern/ in your case. I don't believe that Microsoft will ever fix this issue in Edge, as it is intended behaviour.
I have installed Prestashop and I can see the site and the back office. But my friend that I'm running the site with can't reach it from his computer. Just getting browser default Page not found. Have tried turn off all cache and IP settings in PS. And clear the browser cache. But nothing works.
What is the problem?
New to IIS8, but previously created sites on an IIS7.5 server without any problems. I've created a site on IIS8 and although the pages are being served to remote computers, when I click 'Browse Website' in IIS, the server itself cannot see the page. Any suggestions? Could it be permission based?
I feel this may be linked to a problem we're having downloading images.
You didn't mention the specifics of "the server itself cannot see the page". However, since you can access the site remotely but not locally, it sounds like it may be anti-loopback checking. Check out http://blogs.msdn.com/b/jiruss/archive/2008/10/21/loopback-security-check-feature-iis-7.aspx and see if it applies in your case.