Try these steps:
Find or create a web server (Apache, Node.js, ...) that you can control
Find or create a resource to be served by said web server
Shutdown web server
Try to access a resource at that server's address in Chrome
Notice: ERR_CONNECTION_REFUSED page is shown
Start web server
Notice: Chrome automatically reloads the request.
I have two questions:
How does Chrome accomplish this? Is it just repetitively polling the server somehow?
How could I investigate this myself?
I've tried a few different google searches, but all I can find are support forums for chrome not connecting or pages being unavailable.
Related
Background: I have a web app that is accessed via Chrome on a Windows 10 machine.
I also have a native Win10 application installed on the device. The web app sends data to the Win10 application via a local web service running on the machine in IISExpress.
To allow for HTTPS communication on port 44300, I've created a self-signed certificate via PowerShell:
New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddMonths(60)
And then imported it to 'Local Computer\Trusted Root Certificates\Certificates'
From within the web app I send a command to the win10 app that looks something like this:
https://localhost:44300/CMTService.svc/JumpToAssignment?Param=Key=418584577
The win10 app is polling for these requests and picks up the message.
Issue:
Different versions of Chrome behave differently with the acceptance of the self-signed certificate. For instance versions 62, 64 and 75 all accept the certificate and allow for communication with the web service. But other versions of Chrome like 76 and 78 block communication. The Security tab in the Chrome DevTools shows https://localhost:44300 as "Unknown / cancelled" and my requests fail with ERR_SSL_CLIENT_AUTH_CERT_NEEDED. Whereas in working versions of Chrome my URL shows under "Secure origins". The only thing that I change is the Chrome version to get these different results.
I've tried enabling the Chrome setting to allow for invalid certs for localhost (chrome://flags/#allow-insecure-localhost). This temporarily works, but then after closing and reopening chrome, my requests start failing again with the same error code.
If I take one of my failing URLs and paste it into a new Chrome tab, suddenly communication with my native app in my web app resumes as normal. But it only works for that session - when I close and reopen Chrome my communication is broken again.
Question:
How do I allow for communication between my Chrome v78 web app and my local native app?
ERR_SSL_CLIENT_AUTH_CERT_NEEDED means the server is asking the browser for a certificate for client authentication.
You've described how you setup server authentication, but not described how you setup client authentication.
Likely you have enabled certificates for client authentication, but have not configured the web app to send the correct client certificate or have not configured the native app to accept the correct client certificate. That's a very open ended topic to be prescriptive without knowing more about your development efforts, but you can confirm if client authentication is enabled by inspecting a packet capture. One description of the handshake is here : https://blogs.technet.microsoft.com/nettracer/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication/.
Just an update: I implemented a javascript workaround to get around my communication issues. When first loading the web app, I simply send my first communication to IIS (destined for Win10 native app) in a separate chrome browser tab. For whatever reason this allows for successful acceptance of the certificate and kick starts the communication with IIS. This is my code to send the command in a new tab and then close it:
var inst = window.open(launchWinAppURL);
if (inst != null) {
window.setTimeout(function() {
inst.close();
}, 1000);
}
This is not the most elegant solution, but it seems to work on all chrome versions, so i'm satisfied.
Is the web app only communicating with the one win10 machine? Have you installed the self-signed cert directly to the machine? I would try installing it directly to the machine and see if the later instances of chrome allow communication.
So this is kind of odd.
My scenario:
Web server running IIS, hosting asp.net applications
SQL server
As they are on separate servers, I had to set up kerberos delegation. I have got this working.
So a user goes to asp.net application hosted on the web server, and it authenticates them to the SQL server.
On one of my web apps, when they go to it in Chrome, I get the error page with SQL authentication failed due to Anonymous user. If they go to the same app in IE, it works correctly.
Here is the really odd part - if they then go to it again in Chrome, it works!
So I guess there is some inconsistency in how Chrome authenticates.
I found someone suggesting it might be to do with the IIS negotiation providers, but as it needs kerberos delegation I have to have "Negotiate" as the first option or it fails completely.
I guess I could just tell users they have to use IE, but I would prefer to get it to work in Chrome.
Any thoughts?
(Possibly similar to Kerberos not working with Chrome but it's all on intranet zone, so don't think there's anything to whitelist)
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
I have asked a similar question before here I sort of fixed it but im still facing a similar issue. Every time I try to load localhost, port 8095, I receive this error message in Google Chrome:
Google Chrome's connection attempt to localhost was rejected. The
website may be down, or your network may not be properly configured.
If there is a way to fix it, please tell me,
If not, please could someone inform me how to reset IIS to its original settings. Or if I can reset Windows Features so I can re-install ISS from scratch.
My website uses ASP with a connection to a SQL Server database (2012). Basic HTML pages also don't load under the URL, localhost:8095/
The servers were stopped because 2 services within administrative tools had stopped. World Wide Web Publishing Service and Web Management Service
I'm having a strange problem with a separately hosted subdomain I have. I'm running an application on Engine Yard, let's call it mysite.com. I have a wildcard SSL certificate installed there which covers all the subdomains (things like api.mysite.com). We recently decided to migrate our blog to be hosted independently (right now it lives on wordpress.com). Because I can't run the blog alongside our Rails app with ease on Engine Yard, I decided to grab some cheap hosting space from Dreamhost to host our Wordpress blog there. I set up the server there to fully host our subdomain (let's call it blog.mysite.com), and updated the DNS A record on Hover (our DNS provider) to point blog.mysite.com to the Dreamhost server. So here's the issue:
If I go to blog.mysite.com via Firefox or Safari on my Mac I see the basic Wordpress install which I set up. However, if I try to view things with Chrome I get the following error:
This webpage is not available
Error 118 (net::ERR_CONNECTION_TIMED_OUT): The operation timed out.
This happens on all Macs running Chrome I could get my hands on. I tried both clearing the cache and flushing the DNS but nothing. The weirdest part is Chrome keeps looking for https://blog.mysite.com instead of http://blog.mysite.com. There is no SSL cert installed on the subdomain for the blog on Dreamhost because it's not necessary.
Has anyone ever come across this before? And in case anyone wants to try the actual address is http://blog.frestyl.com.
sounds like you have a 301 permanent redirect that Chrome registered http://blog.frestyl.com -> https://blog.frestyl.com. Besides clearing the cache I'm not sure what else can be done.