FireFox - None of the "sha256" hashes in the integrity attribute match the content of the subresource
We created a web site that uses resources from cdnjs. This site has been live for a couple of months but we have sporadic issues with resources from this CDN and FireFox.
- The error in the console for each script/style CDN resource is:
None of the "sha256" hashes in the integrity attribute match the content of the subresource.
- The error message in the network tab for each resource is:
The connection used to fetch this resource was not secure
Resources that I have had issues with include these elements (as they appear in our web page):
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap3-dialog/1.35.4/css/bootstrap-dialog.min.css" integrity="sha256-wstTM1F5dOf7cgnlRHIW3bmoRAAGh6jL7tMIvqTuFZE=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap-datetimepicker/4.17.47/css/bootstrap-datetimepicker.min.css" integrity="sha256-yMjaV542P+q1RnH6XByCPDfUFhmOafWbeLPmqKh11zo=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/jqtree/1.4.4/jqtree.min.css" integrity="sha256-ymsp1QFcwiJbIgAoSOkMtqe4GFczZH1KjXLq6y5f+QY=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" integrity="sha384-wvfXpqpZZVQGK6TAh5PVlGOfQNHSoD2xbE+QkPxCAFlNEevoEH3Sl0sibVcOQVnN" crossorigin="anonymous" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/bootstrap3-dialog/1.35.4/js/bootstrap-dialog.min.js" integrity="sha256-IpgnbT7iaNM6j9WjtXKI8VMJ272WM9VvFYkZdu1umOA=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.15.2/moment-with-locales.min.js" integrity="sha256-K+AZsAFjiBd4piqBmFzaxDsiQiHfREubm1ExNGW1JIA=" crossorigin="anonymous"></script>
Steps to reproduce
You can reproduce the problem with one of the above URLs and place it directly in the URL of the FireFox browser. The resource should load in the browser window but after pressing CTRL+F5 at least one time (could be up to 5 times) an error will appear. I can duplicate this from multiple PCs although we are located in the Netherlands so maybe a timing issue or something similar (beyond my expertise)?
This does not happen with any other resources from other CDNs that we are using like the following:
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
My environment:
- Windows 10 Pro 64bit patched to latest
- FireFox 60.0.1 (64-bit)
My question
Is this an issue that is specific to cdnjs and they must resolve this or is this an issue with FireFox or is this an issue with how we are requesting the resource?
As a side note we also regularly test our software on Google Chrome, MS Internet Explorer 11, MS Edge, and Opera and have never experienced this problem on these browsers (or any other for that matter).
I have already created a post on Mozilla's forum but the response was that this is out of scope with a recommendation to post it on SO or submit a bug on GitHub. I have not done the latter becomes I am not (yet) convinced this is a bug in FireFox. I have also submitted an issue on cdnjs's github repo.
Answer
TL;DR: similar problem on Linux (RHEL 7.3) with Firefox 45.6.0 was solved by downloading 60.0.2 from getfirefox.com.
I'm afraid this is unlikely to solve @Igor's problem, but I had a very similar problem and solved it with a Firefox upgrade; perhaps this will help others.
In my case I was seeing the same
The connection used to fetch this resource was not secure
message in the web console's Network tab not only for Cloudflare but for several other sites:
- https://cdnjs.cloudflare.com/
- https://ajax.googleapis.com/
- https://www.googletagmanager.com/
- https://www.google.com/
- https://www.youtube.com/
- https://www.mozilla.org/ (!)
Chromium, however, was unaffected (as were lynx and curl).
Given the error message for failures, I poked around in Preferences -> Advanced -> Certificates -> View Certificates and was immediately suspicious of all of the expired ones (since 2014!) in the Servers tab, including www.google.com. Attempts to delete them failed, however; they came back immediately after retesting any of the problematic sites in a new tab.
Every suggestion on the Mozilla help pages also failed: no proxy, no anti-virus, safe mode, refresh profile, switch to a brand-new profile (also got bogus 2014 certs, so clearly hard-coded), disable hardware acceleration, disable DNS prefetch, and several other about:config hacks. Reinstalling the existing Firefox version via yum also failed, as did manual deletion of all sqlite files and most of the relevant-looking sites under storage/default (all within $HOME/.mozilla/firefox/<profile>). Even Mozilla's own certutil failed to read the freshly minted cert8.db in the new, clean profile:
$ certutil -L
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
I even tried to reload Firefox's root certificates via the Import option in the Advanced preferences page for 45.x, but the plain-text version I found on Mozilla's Mercurial repo apparently wasn't understood by Firefox's import button. (Or maybe it was; there was zero feedback. But the expired stuff on the Servers tab didn't go away.)
I mention everything that didn't work both because several of those actions did help others who reported similar problems, and also because running through all the possibilities (and several intervening discussions with colleagues) took a huge amount of time.
Ultimately, grabbing the latest Firefox binary via
and unpacking the tarball in a local directory worked fine, and it took all of two minutes to complete and verify. Both old and new profiles work fine with it. And lo and behold, the Servers tab is completely empty of all certificates, expired or not. In my case, I'm pretty sure that was the problem, and my inability to delete the bogus certs was a bug in 45.x.