I have created several virtual hosts for my development processes. They were working just fine till yesterday. But in my chrome app, today they stopped working. Chrome shows: NET::ERR_CERT_AUTHORITY_INVALID
All my vhosts end with .dev. I changed one .dev to .work and its again working. But I can not do this for all vhosts as there are too many of them. What do I do?
PS:
They are working fine in firefox.
The error remains same in chrome incognito mode.
I tried clearing cache and hard reload, deleted my history and cache, restarting chrome even windows multiple time, nothing works.
In one solution, I found an exception can be included in chrome://net-internals/#hsts. I tried deleting domain in there but somehow it still appears in Query Domain search.
Chrome have switched the .dev sub domain to HTTPS only.
They have done this by turning on HSTS for this top level domain, but by preloading this in the Chrome code rather than sending the HSTS header. This means it cannot be switched off in the chrome://net-internals/#hsts screen.
More info:
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
So you’re only options are:
Update you’re vhosts to a different TLD (e.g. .test). And yes this might be painful because you have so many.
Move to HTTPS by creating a certificate and updating your URLs. A self signed certificate that you can create yourself will do, however note that HSTS not only blocks accessing the site over plaintext HTTP, but also prevents you clicking through certificate errors. So you’ll need to manually accept any certificate to your trust store before it can be used.
The chrome team have been pushing HTTPS more and more and certain features are now HTTPS-only so even dev envs will need it now. So maybe it’s finally time take the effort to make the switch.
Related
I have a website that supports HTTP2. If I use Firefox or Chrome in anonymous mode then all the calls are made with HTTP2 (shown as h2 in Chrome developer tools Network tab).
When I use ordinary Chrome though it does exactly the same call but uses HTTP1.1 for some reason. I have tried to turn of all extensions but it is still HTTP1.1.
Sometimes if I restart Chrome is starts using HTTP2 again but then falls back to HTTP 1.1 after a while or after one of the restarts. I cannot figure out what can be the problem and it looks very mysterious.
I did not change any settings explicitly in Chrome if they even exist. What can be the problem here?
P.S. I did "clear browser cache" and "clear browser cookies" and suddenly I got only http2, don't know how this ca affect protocol. This was a temporary improvement though and I got http1.1 after a while again
P.P.S. I have even got a case when loading a website that one request was http1.1 but the other one was http2 to exactly same server.
We have a web application that runs within a VPN. It has a self signed cert on it and is accessed through the server's IP address.
Part of the functionality of this app are some legacy Java apps (that no longer run in Chrome). Our initial work around for our Chrome users was to run Shell In A Box within an iframe of the web app to run those. All was good until the latest version of Chrome, v45.
What we’re seeing is that appears to be blocking the iframed content (maybe because of the self-signed cert?). If we grab the ShellinABox URL and drop it in a new tab, it works as it used to in the iframe. If we go back to the iframe, it now works. If we close Chrome and open it back up, it still works.
I should also note that we tried the canary builds as well. It's up to v47.x and we still see the same behavior there. We were reading through some of the Chrome group/bug lists and saw some reports that were similar but the "fixes" supposedly going through canary still didn't resolve it.
So, it appears that an exception is being logged somewhere. Does anyone have an explanation for this behavior and is there a way to set this exception without jumping through those hoops?
It turned out it was due to a permissions issue with ShellInABox that didn't reveal itself until v45 of Chrome, for some odd reason.
Whenever I try to visit log in to PayPal on Google Chrome (my current version is 35.0.1916.114 which is the most up to date at the time of writing this), I get a 500 Internal Server Error. Here's the exact one:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#paypal.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
I'm able to visit the homepage fine and I can log in on all other browsers but this has been an issue for some time now (I just haven't gotten around to looking into it). At the moment, I open Firefox just to use PayPal but I used Chrome for everything else so I'm trying to solve it.
Any ideas on why this would be happening? I've seen other questions on the web similar but they are mainly due to people 'buying' through PayPal which isn't a problem for me. I can purchase items on the 'purchase' screens that you get redirected to from a site.
Thanks for your help!
I see this from time to time on a couple of very specific web sites (e.g., Slashdot). All other sites works fine when this happens (and the site works fine in other browsers, including Web Kit based ones). The embarrassingly simple solution is to restart the browser (I try to avoid it since I often have 50+ tabs open). If guess the problem might be session cookies (that would explain why a restart works). As a consequence of this guess, clearing all permanent cookies for PayPal and related sites might be worth considering.
For me, I do like this at the 500 error page
Click on the Secure to the left side of the address bar
Select Site settings
Select Reset site settings at the bottom of the page
Reload the page
in some cases but not all. There appears to be a corrupt session via the cookie or data stored for a specific browser in the java files. Try the following;
1. Download CCleaner (close chrome)
Remove and clean registry files
Remove tmp and cached for CHROME as well as cookies
Clear index.dat file
4. Control Panel / Java-open / clear internet java cached files
5. Make sure you're not using a proxy IP for the web
6. Restart computer
7. Try again
Now that Google separated cookies from permissions I had to delete my cookies separately to get it to work.
Click on the Secure to the left side of the address bar
Select Cookies
Select the wordpress cookies and Remove each one
Reload page
I have an existing site that works fine over http and https (SSL). The SSL certificate is valid and can be confirmed by inspecting in the browser.
I am starting to use a manifest file to enable the HTML5 application cache on my website. This is useful for making the page load faster, and eventually for offline capabilities. This is working great when using a regular http connection. The problems happens when accessing the site over https (SSL). When I do this, I can access my website's content just fine, and the URL says "https" however I see the following behavior:
Safari: It displays the lock icon, but when I click the lock icon to inspect the certificate, it says that the certificate is invalid.
Firefox: Does not display the colored address bar indicating encryption, and when inspecting the certificate, it says that there is no certificate.
Chrome and Opera: Correctly displays the secure nature of the URL, and when clicking the lock icon it displays the SSL certificate information. Yes!
I understand that using the application cache causes resources to be served locally from the browser, and as such there is no encryption happening, however customers don't necessarily know that there is an application cache happening in the background, and they are expecting to see a valid SSL certificate and indications that the connection is secure. Safari and Firefox appear to be doing this incorrectly, unless I am missing something. That is my question. Does anyone know how to get Safari and Firefox to display the SSL certificate for pages served from the application cache? Is there something special that you need to do, or is it a Safari and Firefox bug?
I believe someone has discussed this with me before. Please let me know if this helps.
Change all of your script and css references from
http:// or https:// to //.
If you haven't any then it is moot, but if you do, please let me know if that has an effect.
I believe this may be related to not being able to verify the references from a cached page.
Based on the history of vulnerabilities, I'd guess this may have been overlooked for the sake of fixing more critical issues. That said, I think this should be reported to both vendors now that some of the glaring vulnerabilities have been patched. Have you tested this with the latest releases of Firefox and Safari?
Did you serve the application manifest over SSL?
Trying to set up an encrypted connection for an intranet site. It's for a small company and not dealing with any sensitive information, but still would like to avoid login and password information sending in the clear. Would also like to avoid having to buy a certificate if possible.
I tried creating a certificate with OpenSSL and got everything set up and the site works over an HTTPS connection, but the web browsers are all showing warning messages. So, I googled around and found that I could add the certificate to Windows' Trusted Root Certification Authorities. I tried this, but am still getting the warning messages and "red x" https logo. Also tried importing the certificate into Chrome through the options screen but no luck.
How can I get my internal machines to trust my self-signed SSL certificate and not show a warning message?
I think Mr. Leahy's suggestion to use a name with DNS-like qualification would work. Here's Chromium patch information related to the error:
http://groups.google.com/a/chromium.org/group/chromium-checkins/msg/9fe59a981479aa44?pli=1 (r62178)
If the host name denotes an "intranet host", which in the code means one with either no dot in the name or a dot at the end, then it is considered non-unique, and you get the warning. After quickly looking through other patches involving the warning, I didn't find a way to tell Chrome to relax about the warning.
Im not sure this will apply to your question but I had a similar experience a few days back where chrome would show an insecure site (red cross through the EV ssl)
In my case it was because some links from google apis were over http not https
thus MAKE SURE ALL YOUR EXTERNAL RESOURCES ARE CALLED OVER HTTPS not http!
I stumbled across the same issue today and found a stunningly simple solution:
It turns out that a bad certificate override is displayed during the entire chrome session even if the certificate has been validated or renewed in the meantime.
Restarting chrome fixes that.
If the certificate warning is still present after the restart, then You will have to look at the other answers.