Saw this error a few times today in Chrome's developer tools, and trying to figure out what it means / what we can do to avoid it.
"Failed to load resource: net:: ERR_CERT_DATABASE_CHANGED"
This was causing some image urls to fail to load in our testing. Fwiw I just checked the cert for the site in question, and it was issued over a year ago and is valid until the end of 2016, so it doesn't look like any changed serverside.
Google search turns up pretty much nothing for this error message, so hoping Stack Overflow will have more answers.
So the best I've been able to discover is this: https://chromium.googlesource.com/chromium/src/net/+/master/spdy/spdy_session_pool.cc and a few related tickets in Chromium about this code. It would appear that when the system cert database changes - in my case, potentially just a crappy puppet policy double checking that only trusted certs are in our store - Chrome reacts by closing down all existing connections and returning network errors to any outstanding request.
I had the same problem.
You may have Kaspersky Antivirus installed.
The Kaspersky software is manipulating the system keychain frequently (sometimes many times a second), which is causing Chrome to flush connections, because the system trust store has changed.
You can try it:
Remove Kaspersky;
disable Kaspersky web traffic interception
I also found a page with a description of the bug https://bugs.chromium.org/p/chromium/issues/detail?id=925779#c29.
Related
Recently I am facing an issue with google meet in firefox as well as chrome. In the google meet call the other person cannot hear me and after a few seconds the call disconnects saying network issues.
1] Console shows the above error message.
2] There are no 400 or 500 responses in the Network tab.
3] Happens across both my systems. Pfsense is a firewall I have which I cannot turn off.
Has anybody faced this issue or let me know what can be causing it.
This issue was resolved after purging cloudflare-warp, removing system wide certificates from /usr/local/share/ca-certificates/extra and reinstalling the latest version (at this point 2022.7.x)
Few days ago I had same issue with windows/linux clients behind an enterprise network, using http proxy.
Workaround applied was forcing default mic/cam chrome permissions to "ask(default)", not "allow". Haven't found root cause yet. let me know if it was effective. regards.
Since yesterday afternoon, I have not succeeded in using Folium to generate maps, even the most basic display function can not be completed, the network connection is normal, it is likely that there is a problem with the call of js.
I tried switching the network environment and trying to change computers, but it didn't work.
Failed to load resource: net::ERR_CERT_DATE_INVALID
leaflet.awesome-markers.js:17 Uncaught ReferenceError: L is not defined
at leaflet.awesome-markers.js:17
at leaflet.awesome-markers.js:122
leaflet.css:1 Failed to load resource: net::ERR_CERT_DATE_INVALID
map.html:39 Uncaught ReferenceError: L is not defined
at map.html:39
#This is the code for the most basic function I've tried.
import folium
m = folium.Map(location=[29.488869,106.571034],
zoom_start=16,
control_scale=True,
width='50%')
m.save('map.html')
I hope to generate map pages
I dont think there is any problem in your jupyter notebook/Python IDLE. Check with your browser. If you’ve determined that the ERR_CERT_DATE_INVALID is caused by an issue on your computer, try these steps to resolve it:
First things first, check the Date and Time set on your computer, if
these are wrong it probably explains how you got the
ERR_CERT_DATE_INVALID error.
Sometimes fixing this error is as simple as shutting down your
browser and then restarting it. Other times a system reboot may work.
However, there are a couple of instances where you’ll need to do a
little more work to set things straight.
Check your connection, if you’re connected to public WiFi or some
other public network there’s a chance that your browser is right and
you don’t actually have a secure connection. If that’s the case, stop
browsing and resume when you’re on a more secure setup.
Scan your computer with a trusted antivirus software, you may have
malware of some sort that is causing the issue. Unfortunately we
can’t provide you with info on how to fix every last piece of
malware, but if your antivirus can’t, someone on the internet
probably knows.
Disable any third-party plugins you have running on Chrome. Sometimes
these can cause unwanted problems.
Clear your browser cache on Chrome. Click the menu icon, open History
and select “clear browsing data.”
Delete and then re-install Chrome. Sometimes this helps.
There are a few other crazy fixes like bringing down your firewall or
modifying network settings. However I would not suggest this one since your PC then become susceptible to virus.
I have Adblock and Adblock Plus extensions in Chrome browser. I spend a lot of time doing intentional shopping and get blocked from things I don't want to be blocked from. For example if I search google for a "hotspot", I want to research various devices available. But when I click on one (sponsored link at the top of the search results), I get an error page that says
This site can’t provide a secure connection
ad.doubleclick.net sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR
I don't mind these "ads". They are useful. Is there a way to configure AdBlocker to allow them?
My IT department admitted this is a filtering policy. Quite unfortunate since looking at ads for new technology IS A HUGE PART OF MY JOB
I've been working with Appcache for quite some time, but I recently took a couple of weeks to develop a different project. When I returned to my offline project, I started getting this error every time I try to download the contents of my manifest:
Application Cache Error event: Manifest fetch failed (9)
This is followed by 2 addresses; the file and line number of the page that calls the manifest (on right of same line), and the relative url of the manifest itself (on a second line). The download of the individual resources does not begin.
Now, other folks work on this project, but I'm the only guy who touches anything that as much as smells of offline. The issue doesn't appear to be related to any of my usual suspects, like a syntax error in the manifest (tried clearing all the files, just to be sure), the manifest being served incorrectly, or something wrong with one of the files being cached. I don't think it's a memory problem, as I have over 30 gigs of space outside of the size of the files I'm caching. Furthermore, this worked 2 weeks ago, so I'm assuming that there isn't something wrong with my setup. However, nobody seems to know what the hell this error is; nobody even seems to be getting this error. I can't find anything online to describe what this issue is. Hence, my question is:
What does Manifest fetch Failed (9) mean?
My browser is Chrome on Windows 7, and is up to date.
GAH. Ok so I figured out the problem, or at least I figured out a solution. 9 might indicate a certificate error, which is what I was experiencing. Lovely, just... lovely.
(9) means that there is a security error. Since cache manifests with invalid certificates allow a man-in-the-middle attack, as explained in the Chromium issue that disallowed this. If you still want to use a cache manifest with an invalid certificate for testing purposes, you can pass --ignore-certicate-errors to Chrome on launch.
I'm having some issues with Chrome canceling some HTTP requests and I'm suspecting cached authentication data to be the cause. Let me first write down some important factors about the application I'm writing.
I was using Basic Authentication scheme for some time to guard several services and resources in my web app.
In the meantime I was using/testing the app heavily using Chrome with my main Google Account fully synced. Most frequently I was using my name - "lukasz" - as the username in Basic Auth.
Recently I have switched my application to use Digest Authentication.
Now, some of the HTTP requests I'm making are failing with status=failed with no apparent reason. It only happens when I'm using user "lukasz", if I enter some other unique username - there is no problem.
I looked everywhere in the backend and frontend and I couldn't locate the issue to be in our code. I can easily reproduce this with user "lukasz" each time. So I reverted my code to Basic Auth (while not touching the rest of app) and the problem was gone.
That led me to think that there is something wrong with cached passwords. So I cleared the cache in Chrome, but that didn't help. After several hours of analyzing the issue I decided to make sure that I'm running fresh instance of Chrome, so I reinstalled it (deleting the disk data along the way). TADAAA! The problem was gone and I couldn't reproduce this anymore.
Then I synchronized my Google Account with this newly installed Chrome and after a short while the requests to my app started failing again!! So I took a deeper look at this (cleaning profile data from disk and redoing all the steps) and indeed it looks like the problem starts as soon as my account is synced with cloud!
Yes, I know it sounds dodgy. It sounds ridiculous. It sounds stupid. But I am almost sure that those two problems are somehow related (failing requests and account sync).
My idea is this: Chrome somehow remembered that I was using "lukasz/my-pass" with Basic Auth for certain services. After I switched to Digest Auth the same combination of credentials (lukasz/my-pass) is now acting funny. Perhaps under the hood Chrome still thinks that this is Basic Auth and cancels requests when it learns otherwise?
UPDATE:
I've did some low level debugging with chrome://net-internals/ and it appears that the problem is while reading cache entry. This seems to prove my initial assumption.
I did some investigation and found this article. Apparently always adding "Last-Modified" header to my http response has solved the issue in Chrome (I'm still having some problems in FF, but that's off topic).
However, it still doesn't solve my issue entirely. Why the requests were failing in the first place?
You could try using incognito mode and see what happens. It may give you some hints without having to clear the cache or re-installing Chrome.
Also take a look at How to clear basic authentication details in chrome