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 added new site in IIS
When I'm trying open site in browser it is showing DNS error
trying to resolve it since 5 days but I'm unable to solve this issue. please help
I'm using windows 10 OS
It's because the host name is not recognized by the DNS server that your browser is querying looking for the IP address. You can get around this by editing your hosts file at c:\windows\system32\drivers\etc\hosts (there is no file extension on this file). Here's a link explaining how to edit this file: http://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/
Once you get into your hosts file, add an entry for your local website like so:
127.0.0.1 admin.vdeliver-local
Save the file, then clear your browser's cache and then you should be able to visit the site.
I have defined some virtual servers that until the last days were working fine.
Now they don't on Chrome, but there are no problems in firefox or safary.
I get this:
This webpage is not available
ERR_ICANN_NAME_COLLISION
Hide details
This site is using a new generic top-level domain (gTLD). If you have
used loc.dev to access an internal site in the past, contact your
network administrator.
I found as a solution:
Set the "Built-in Asynchronous DNS" to "Disabled" in chrome://flags, but the is no such flag in my chrome version ( 43.0.2357.81 )
Do you know a solution for this?
LE : If i move the site on the htdocs file and i go on the url http://localhost, it works. It seems that it has a problem only with virtualhosts.
Got the same issue after updating to the latest chrome version last night. I was getting a ERR_NAME_NOT_RESOLVED error only on google chrome for all of my virtual hosts. Here's how that looked.
Screen Shot-> DNS name not resolved error
Here's the fix I made.
Clear up the google DNS cache by typing this in the Chrome browser
chrome://net-internals/#dns
Screenshot -> Flushing Chrome DNS cache
You will see a button "Clear Host Cache". Press that DNS cache
will be flushed.
Keep this DNS window open. Now access the virtual host in the browser
for me it was http:/api.localhost. Once you do that you will see a
new entry in the DNS window. for me it was "localhost."
notice the period "." at the end of localhost that showed an error.
Last step is to simply add this entry as to your localhost file.
Your hosts file should be updated with an entry to resolve localhost. to 127.0.0.1:
# dont forget the trailing . !!!
127.0.0.1 localhost.
in the hosts file located at:
for linux : /etc/hosts
for windows : C:\Windows\System32\drivers\etc\hosts
Another solution for your case might be to ditch the .dev at the end of your local virtual host domain
This has to do with some new changes by google. ".dev" comes under google's TLD (In the corner of the internet where people care about DNS, there is a bit of an uproar at Google's application for over a hundred new top-level domains, including .dev)
Try this Use a domain name you own. Possibly using the full name like "localhost.dev.$yourdomain" could help you here depending on your setup.
With the 'chrome' I face the same issue because by mistake I comment out the
127.0.0.1 localhost from the host file, But 'Firefox' will work.
Just make sure your host file include
127.0.0.1 localhost
FIXING
Try contacting your system administrator.
ERR_ICANN_NAME_COLLISION.
if you are using magento and getting such error
just go to you database and search for core_config_data
click on it then check your web store name
change the store name
restart your wamp and fixed.
Worked for me:
chrome://net-internals/#hsts -> Domain Security Policy -> Delete domain security policies -> enter there localhost and press delete
Here is another catch for you, my virtual hosts in Windows hosts file were defined as:
127.0.0.1 bla.bla.bla.localhost
127.0.0.1 bla2.bla2.localhost
And actual server virtual host directives in Xamp Apache Vhosts file made it all work nicely in all browsers, but Chrome!
A simple fix - dont end with full "locahost" word, rename the vhosts to end with anything else, just "loc" did it in my case, all works in Chrome now!
Been having this problem with Version 56.0.2924.87 (64-bit) of chrome, attempting to access a vm by gset.localhost, just would not work.
Changed the url in the hosts file to gset.loc and it works fine.
The answer seems to be do not use localhost in your hosts file urls when attempting to access a virtual machine running on your machine using chrome.
All browsers - chrome, firefox, safari were not resolving my virtual host and kept re-directing to www.mysite.dev
After pulling my hair for hours - it turned out I just need to change mysite.dev to www.mysite.dev in the /etc/hosts file.
I have a website written in HTML5 and have already added it to iis7. I checked to make sure that the path was correct, and both the path and the authentication are reported as being correct by iis. I have a personal DNS that I am using to host the site, and I have the website in IIS being hosted by that DNS. Whenever I go to browse to the site, internet explorer kicks back a page saying it could not connect to the page. It will not let me diagnose any connection problems. Any idea what could be going wrong and how I can fix it?
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.